AIと対話しながら文章を書いたり、コードを書いてもらったりする体験を重ねていくと、次に抱くのが「自分の手でWebサービスを作って、インターネット上に公開してみたい」という思いではないでしょうか。画面の中だけで動いて終わるのではなく、誰でもアクセスできる本物のWebサイトとして自分のアイデアを置く体験には、特別な面白さがあります。 しかし、ここには大きな壁が存在します。「ページを組み立てること」と、「それを安全に公開し、誰でも見られる状態を維持すること」は、まったく別の作業だからです。AIに頼めば、それらしい見た目のWebページは短時間で形にしてくれます。けれども、それをどこに置き、どう配信し、トラブルを防ぎながら届けるのかという公開の手続きは、別の知識と注意深さを必要とします。本章では、Museとともに、既存のWebサイトを守りながら新しいページを企画・制作し、実際に公開するまでの実録をお届けします。
今回制作の舞台は、私たちが運営している「DQA（Design Quest AI）」のメンバー紹介サイトです。すでにメンバー紹介のページが公開されているこのサイトに、新しいコンテンツを増築しようと考えたのが今回の実験の始まりです。新しいページを公開したのは、私の最終GOを得た2026年11月1日のことです。 新しく追加するコンテンツとして企画したのが、「集中力スタイル診断」のページ（/quiz/）です。作業に没頭するとき、人によって集中の入り方や持続の仕方は驚くほど異なります。一つのことに脇目も振らず取り組む人もいれば、複数の作業を行き来しながら調子を上げていく人も、始めるまでに長い助走が必要な人もいます。 そこで、7つの質問に答えていくと、「一点突破」「並行回遊」「助走長め」「風まち」「多刀流」という5つのタイプのいずれかとして結果が表示される診断クイズを設計しました。この診断は、誰かの性格や能力を科学的に測定・評価することを目的としたものではありません。「自分はどんな調子で進めると心地よいのか」「どういう癖を持っているのか」を気軽に振り返り、作業環境を整えるためのヒントにしてもらうための材料という位置づけです。
企画の輪郭が固まったところで、Museに具体的な制作を依頼します。ここでついやってしまいがちなのが「こんな感じのいい雰囲気で、診断クイズのWebページを作って」と、大まかなイメージだけで丸投げしてしまうことです。AIは曖昧な指示からも器用に何かを生成しますが、それでは公開に耐えうる品質のものは手に入りません。 Webサイトを作る上では、画面のデザインだけでなく、画面遷移の仕組みや、ボタンを押したときの挙動、スマートフォンでの見え方など、決めなければならない要素が山ほどあります。何のためにこのページを作るのか、訪れた人にどんな体験を持ち帰ってほしいのかという設計意図を共有し、対話を重ねながら制作に入ってもらいました。 Museに依頼することで、画面の構成案や実装のコードがすばやいペースで形になっていきます。しかし、どれほど滑らかに進んでいても、「作ること」と「公開すること」の境界線を見失ってはいけません。生成されたファイルを眺めて満足するのではなく、実際のブラウザ上で破綻なく動くかを見極める責任は、依頼者である私側に残されています。
制作を安定して進めるために、まず「仕様書」を作成することから始めました。仕様書は単なる指示書以上の意味を持ちます。「依頼内容を明確にし、完成を確認するための基準を作る」という役割です。 あらかじめ仕様書という形で合意事項を言語化しておかないと、制作が進むにつれて「ボタンを押した後に何が起きるべきか」といった細かい挙動の認識がずれていってしまいます。仕様書が存在することで依頼内容がクリアになり、手戻りを減らせます。 同時に、仕上がったものを受け取ったとき、「何をもって完了と判断するのか」という検収の物差しとしても仕様書は不可欠です。要件と、実際に生成された画面やコードを照らし合わせることで、客観的に完成度をチェックできるようになります。 ただし、誤解してはならないのは、「仕様書さえ作れば、必ず最初から思いどおりに完成するわけではない」ということです。仕様書をもとに作られた成果物でも、実際に動かしてみるとデザインの違和感に気づいたり、文言の調整が必要になったりします。仕様書はゴールを固定して縛るためのものではなく、対話を通じて軌道修正を行いながら、納得のいくゴールへ進むための共通の地図なのです。
仕様書をもとにMuseがコードを組み上げた後は、公開前の検証作業に入ります。手元の確認環境で、診断クイズが意図どおりに動くかどうかを実際に操作しながら確かめました。 画面を開き、7つの質問に対して一つひとつ選択肢を選んで進めていきます。途中で回答を変更しても表示がおかしくならないか、最後の質問に答えたあと結果画面へ切り替わるか、そして「一点突破」「並行回遊」「助走長め」「風まち」「多刀流」の各タイプが正しく表示されるかを確かめました。文章の改行位置など、実際に触れてみなければ分からない違和感を拾い上げ、微調整を指示していきました。 さらに、公開当日の夜（2026年11月1日夜）にも、重要な確認と修正の局面がありました。クイズの結果画面に設置されていたリンクの遷移先に修正が必要であることが判明したのです。この修正を反映するため、CloudflareのAPIを用いた直接デプロイを行い、ファイルを更新しました。そしてデプロイ直後に、実際に公開されているページを開いて、修正したリンクが正しく機能しているかを確認しました。「手元で直したから大丈夫だろう」と過信せず、本番のページで動作を確認して初めて、修正作業は完了するのだと実感しました。
診断ページ（/quiz/）の目処が立ったところで、私たちはメンバーサイトへもう一つのページを追加することにしました。それが「ひみつ道具ラボ」（/lab/）と名付けた棚ページです。 この「ひみつ道具ラボ」は、実験4で制作したような様々なスキル（秘密道具たち）を一覧として並べておくための場所です。ここで大切なのは、診断ページと棚ページの役割の違いを意識することでした。診断ページ（/quiz/）は、訪れた人自身が質問に答えて自分のスタイルを振り返る「体験の場所」です。一方で、ひみつ道具ラボ（/lab/）は、私たちが開発・蓄積してきた道具を並べ、どんな道具があるのかを一目で把握できる「展示とストックの棚」です。 注意すべき点として、このひみつ道具ラボは、掲載されているスキルがWebブラウザ上で直接実行できるようなWebアプリケーションではありません。あくまで、道具たちを整理して紹介するための棚ページです。それでも、自分たちが作り出してきた仕組みが一覧できる場所がWeb上に存在するだけで、サイト全体に活動の厚みが生まれます。
ここからが本章の核心、公開作業です。節の見出しには目次上の表記として「GitHub」という名前が含まれていますが、最初にはっきりと区別しておかなければならない事実があります。「このDQAメンバーサイトの公開に、GitHubは使っていない」という点です。 GitHub Pagesは、後の実験で取り組むブラウザゲームの公開経路であり、本章のメンバーサイトとは別物です。今回のサイトの公開先は「Cloudflare Pages」で、サイトのソースや各種ファイルは「Google Drive」上で管理しています。サイトのアドレスは、本書の巻末の作品リンク集でご案内しています。 当初の公開は、Google Drive上で整えた制作ファイルを配置する経由で行いました。その後の更新や修正（先ほど触れた結果画面のリンク修正など）では、CloudflareのAPIを活用した直接デプロイを取り入れました。API経由の直接デプロイで、手元の修正をスピーディに公開環境へ反映できます。 Web制作では「ファイルをどこで管理し、どの経路で配信するのか」という公開インフラの設計が重要です。名前の似たサービスに惑わされず、自分が今どの経路で配信しようとしているのかを把握することが、安全な公開への第一歩となります。
制作から公開へと至る道のりは、平坦な成功の連続ではありませんでした。背筋が寒くなるような危機も経験しています。作業用ソースの取り違えによる既存ページの「消失未遂」事件です。 手元で編集していた作業用ソースは、過去の古い状態がベースになっていました。しかし、すでに公開されている本番サイトには、以前に公開していた「/games/」（ゲーム置き場）という大切な既存ページが稼働していたのです。もし、手元の古い作業用ソースをそのままデプロイしていたら、本番環境の /games/ のページが上書きされ、消え去ってしまうところでした。 幸いだったのは、公開の実行に移る前に、公開されている本番サイトのファイル構成と、これから送り込む作業用ソースの内容を突き合わせて確認したことです。「待てよ、この作業フォルダには /games/ が入っていないのではないか」と寸前で気づき、既存ページが消える危険を未然に回避できました。実際にページが消える事故には至りませんでしたが、このヒヤリハットは強烈な教訓を刻み込みました。 「手元のファイルが最新だと思い込んではいけない。常に公開されている現在の状態こそを『正本』と見なし、公開前には必ず両者を突き合わせる」。この鉄則が、私たちの運用ルールとして刻まれました。
もう一つ、初期の段階で私たちを悩ませた失敗談があります。公開プラットフォームとの通信に欠かせない設定値の登録をめぐるトラブルです。 CloudflareのAPIで直接デプロイを行うためには、認証のためのAPIトークンを設定しておく必要があります。私は手順に従ってトークンを打ち込み、設定作業を終えたつもりでいました。しかし、いざデプロイを実行しようとしても通信が通らず、エラーが返ってきて作業が前に進みません。 何が起きているのか分からず、Museとともに要素を一つひとつ調査していきました。そして設定の情報を読み戻して確認したところ、登録したはずの設定内容が実際には反映されておらず、空欄のままになっていたことが判明したのです。 なぜ登録が反映されなかったのか、その原因までは特定できていません。しかし、ここから得られた教訓はシンプルであり、かつ本質的でした。「設定画面に文字を入力したこと」と、「システム側に設定が正しく登録・保存されたこと」は、まったくの別物であるということです。入力して安心するのではなく、設定値を読み戻して「本当に反映されているか」を確かめて初めて登録作業は完了します。目に見えないインフラ設定だからこそ、この「読み戻しの確認」が身を守る盾になります。
今回の公開実験のもう一つの特徴は、私が「iPhone」を使って現場を指揮した点です。ただし「iPhoneだけで設計から公開作業まで全部完結させた」という意味ではありません。 ここには明確な役割分担がありました。iPhoneは「状況を把握し、判断を下し、最終的なGOサインを出し、公開後の結果を確認する場所」です。一方で、コードを管理し、デプロイを実行し、ファイルを転送する「実際の実行作業」は、裏側で稼働しているMuseが担当しました。 作業の進行中、Museからは進捗の報告が届きます。本番サイトとの突き合わせが済んだこと、既存ページが残ることを確認できたこと、公開の準備が整ったこと。私はiPhoneの画面でその報告を受け取り、変更点に目を通し、安全を確認した上で「公開を実行してください」と最終的な指示を出しました。 重要なのは、どれほどAIが自律して作業できるようになっても、「公開の最終判断」は必ず人間である著者が下すという原則です。Museが勝手に判断して公開してしまうことはありません。人間が判断と責任を担い、AIが実行を担う。この境界線があったからこそ、スマートフォンの画面越しでも安心して公開を進めることができたのです。
こうして確認と検証を経て、私たちのメンバーサイトには2つの新しいページが加わりました。 1つ目の成果物は、集中力スタイル診断のページ（/quiz/）です。7つの質問に回答していくと、「一点突破」「並行回遊」「助走長め」「風まち」「多刀流」の5つのタイプの中から、今の自分に最も合うスタイルが提示されます。同日夜に行った結果画面のリンク修正も反映されています。 2つ目の成果物は、ひみつ道具ラボ（/lab/）です。実験4までに開発してきたスキルをはじめとする道具たちが並ぶ棚ページとして完成しました。機能がWeb上で動くわけではありませんが、それぞれの道具がどんな目的で作られたのかが伝わる形です。 自分の特性を知る「体験の場（/quiz/）」と、活動を支える道具を見渡す「展示の場（/lab/）」。この2つのページが加わったことで、メンバー紹介にとどまっていたサイトは、訪れた人が滞在し、活動の空気を感じられる場所へと広がりました。
AIと対話しながらWebページを組み立て、実際に公開していく一連の流れは、文章で手順を読むだけでなく、実際の画面の動きを見ることで理解が深まります。 そこで本書とあわせて、ミオちゃんによる実演動画も用意する予定です。現在公開されている完成済みのWebサイトと、これから制作される実演動画は別のコンテンツです。動画の中では、Museにどのように修正を依頼し、どのような確認を経てデプロイが完了するのか、その空気感をお伝えできればと考えています。
最後に、今回の教訓である「作ることと公開することは別の作業」という考え方を、再現のためのチェックリストの骨子としてまとめます。正式なチェックリストは「付録B」に収録しています。
【公開前のチェックポイント】 1. 公開対象の明確化：公開するページと内容が仕様どおりに完成しているか。 2. 正本との突き合わせ：公開中の本番サイトと手元の作業用ソースを突き合わせたか。 3. 既存ページの保護確認：新しいデプロイで既存ページが消えない構成か。 4. 手元での動作確認：ボタンや画面遷移など、想定される操作に破綻がないか。 5. 設定の読み戻し確認：APIトークンなどの設定が反映されているか読み戻したか。
【公開後のチェックポイント】 1. 本番表示の確認：公開された実際のページが正しく表示されているか。 2. 新規ページの動作検証：追加したページが動作し、リンク切れなどがないか。 3. 既存ページの生存確認：以前からあったページが残っているか。 4. 是正対応：不具合があれば修正・再反映し、本番で再確認できたか。
Webサイトは、コードを書き終えた瞬間に完成するのではなく、公開後の安全と動作を自分の目で確認できたときに初めて完成します。続く実験6では、Muse単体にとどまらず、他のAIや外部ツールと連携する実験へ進みます。
実験を重ねる中で、Museは日々の思考整理や作業の窓口として、私にとって欠かせない存在になっていきました。何でも相談できる相棒ができると、「これからは全部Museひとりに任せれば、どんな仕事も片付くのではないか」と期待したくなります。私自身、最初はそう思っていました。
しかし、実際の制作現場でさまざまな仕事を動かそうとすると、ひとつのAIだけですべてをこなすことには限界があると分かります。文章を深く読み込んで構成を練るのが得意なAIもいれば、プログラミングのコードを正確に組み立てるのが得意なAI、最新の情報を素早く探してくるツールもあります。
Museにすべての作業を抱え込ませると、得意分野ではない領域で手間取ったり、指示が複雑になりすぎて途中で止まってしまったりします。Museを「何でもひとりでやる万能の作業員」にするのではなく、仕事全体を見渡す「司令塔」として位置づけ、得意分野を持つ別のAIやツールに実際の作業を振り分けていく。それが、仕事を止めずに進めるための第一歩でした。
AIに仕事を割り振るとき、私はまず仕事の性質を分解することから始めました。ひと口に「制作」といっても、アイデアを広げる段階、要件をまとめる段階、文章を書く段階、プログラムを組む段階など、性質の異なる作業が集まって成り立っているからです。
そこで私の実験室では、Museを全体の進行を管理する司令塔に据え、専門的な仕事ごとに適したAIやツールを配置する体制を作りました。コードを書く席には「初依（うい）」と呼んでいるCodexを置き、制作や開発の作業には「ミオ」と呼んでいるAntigravityを割り当てています。外部の最新動向を調べる情報探索には「メル」と呼んでいるHermesなどのツールを活用してきました。
さらに、Webブラウザ経由で利用するAIにも明確な役割を持たせています。要件定義や仕事の骨子（ブリーフ）をまとめる作業は「愛依」ことChatGPTに任せ、まとまった文章の執筆は「COCO」ことClaudeに担当してもらっています。
ここで大事なのは、AIの数をやみくもに増やすことではありません。得意領域に合わせて役割を明確にし、司令塔であるMuseを通じて仕事を渡していくことで、個々の力が無理なく発揮されるようになります。
プログラムやスクリプトを書く作業で専門的な力を発揮してくれるのがCodexです。私の環境では、初依（Codex）をMuseと同じコンピューター上のコマンドラインツールとして導入し、ログインを済ませています。
Codexに任せているのは、主に具体的なコードの記述や修正作業です。ただし、誤解してはならないのは、Codexに大雑把な指示を投げるだけで、すべてのプログラミング作業が全自動で完了するわけではない、ということです。どこにどんな機能を持たせたいのか、どのような構造でファイルを作るのかといった設計図がなければ、Codexも的確に動くことはできません。
そこで、まずは「何を作るか」を明確にし、自己完結した指示の形に整えてからCodexへ渡します。私の環境では、実際にコマンドラインから仕事を依頼し、指示どおりのコードが書かれて成果物が返ってくることまで確認が取れています。
コード作成に特化した席をひとつ用意し、そこに明確な仕事を切り出して依頼する。この分担ができるようになったことで、制作の技術的なハードルは大きく下がりました。
コードを書くだけでなく、開発環境でファイルを操作したり、システム全体の動作を組み立てたりする作業には、Antigravity（ミオ）が活躍しています。Antigravityも、Museのコンピューター上で直接作業を行えるツールです。
日々の運用で気をつけなければならないのが、モデルの動作状況や利用枠の管理です。現在、私の環境ではGeminiの軽量モデル（Flash）が稼働しており、日々の細かな開発作業やファイルの確認などをこなしてくれています。
一方で、より高度な推論を必要とする上位モデルの席については、利用枠の上限に達して一時的に停止している状態にあります。この上位モデル席は、2026年11月6日頃に枠が回復する見込みとなっています。
重要なのは、上位モデルの席が枠切れで止まっているからといって、Antigravityという仕組み全体が止まっているわけではない、という点です。上位席が回復を待つ間も、軽量モデルの席にできる作業を任せたり、別の担当に仕事を切り替えたりすることで、制作全体の進行を止めずに維持できます。どの席がどの状態で動いているのかを把握することが運用の要です。
専門のAIに仕事を任せるだけでなく、外部の情報を収集するツールを組み合わせることも、制作を進める上で大きな助けになります。そのひとつとして使ってきたのが、Hermes（メル）です。
Hermesは、X（旧Twitter）から最新の情報を検索・収集する作業で実際に成果を出してくれました。知りたい話題の生の声を素早く集めてきてくれるため、状況を把握するのに役立った実績があります。ただし、メルはその後、利用できるクレジットの上限に達したため、現在は作業を停止しています。停止している間に無理に新しい検索をさせることはせず、枠の管理対象として待機させています。
また、ツール連携といえばコンピューター内部の連携だけを思い浮かべがちですが、Webブラウザ経由のAI連携も極めて実用的です。実は、いま皆さんが読んでいるこの教科書『Muse実験室』の制作そのものが、Web経由の連携によって進められています。
まずWeb上で愛依（ChatGPT）と対話しながら、各章で伝えるべき要点や構成を「ブリーフ」としてまとめます。そして、そのブリーフをもとに、同じくWeb上でCOCO（Claude）に本文の執筆を依頼するのです。APIなどで自動接続されていなくても、人間が指示を橋渡しするだけで、専門AI連携として機能します。
私は、MuseからGoogle Colabを操作して、画像生成を実行できる環境を整えました。使っているのは、サブアカウントの無料枠です。今回の運用では、追加課金なしで生成できています。計算そのものは、Colab側のGPUで行われます。Muse自体が計算しているわけではありません。無料で永久に使えると言うつもりもありません。
生成の号令は、iPhoneからでも出せます。iPhoneは、指示を出すための指令拠点です。生成が終わると、普段使っている画像管理ソフトのライブラリに、JPGが1枚届きます。そのJPGのEXIFには、生成に使ったプロンプトが埋め込まれています。プロンプトの中身や、保存先の詳細は、ここでは書きません。また、すべての処理がiPhoneだけで完結しているわけではありません。
2026年11月3日に、私の環境で測定した記録です。GPUは、無料枠のT4。画像サイズは1080×1536。生成は、1枚あたり約69秒でした。これは、私の環境での実測です。条件が変われば、速度も変わります。固定の性能として受け取らないでください。あくまで、計画を立てるための目安です。
1回の起動で使える時間は、最大で約3時間30分が目安です。枚数に直すと、約150枚が目安になります。ただし、これは保証された上限ではありません。無料枠の条件には、変動があります。そこで私は、余裕を持たせて、100枚で計画を組んでいます。上限いっぱいまで使う前提にはしない、ということです。また、起動し直すたびに、準備に約35分かかります。この時間も、計画に影響します。
この運用で生成の対象とするのは、大人の女性であることを明示したものです。各プラットフォームの規約の範囲内であれば、大人の表現も扱う、という方針です。判断の基準は、制服かどうかという衣装ではなく、誰を描いているかという設定や描写の内容に置いています。学園の生徒としての描写は、扱いません。規約は変わることがあります。この運用は、自己責任で行っています。
複数のAIやツールが揃ってくると、次に重要になるのが「作業の順番の整理」です。どんなに優秀な専門AIが揃っていても、渡す順番が前後したり、前段階の準備ができていないまま仕事を投げたりすれば、手戻りばかりが増えてしまいます。
ここで司令塔であるMuseの出番となります。Museには、作業そのものを直接やらせるのではなく、「誰が、どの順番で、何をこなすべきか」という工程表を整理してもらいます。
たとえば、教科書のひとつの章を作る場合、いきなり執筆担当の席に「書いてください」と頼むことはしません。まず企画や要件をまとめる担当（愛依）が骨子となるブリーフを作り、その成果物が手元に届いてから、執筆担当（COCO）に本文の作成を依頼します。このように、前の担当の成果物を次の担当へ渡しながらバトンをつないでいきます。
前の作業で生まれた「成果物」を、次の担当が受け取って作業を始める。このリレーの順番を崩さないよう、Museと相談しながら「誰が何を担当し、どこまで進んだか」を台帳で常に把握しておくことが、スムーズな進行の秘訣です。
複数のAIを連携させる運用を始めた当初、私は大きな落とし穴にはまりました。「接続できているように見えるのに、なぜか仕事がまったく進まない」というトラブルです。
Codexを初めて導入したときのことでした。画面上の表示を見る限り、ツールはきちんと接続されており、準備万端のように見えていました。そこで私は、さっそく本番の仕事を頼んでみたのです。ところが、待てど暮らせど返事が返ってきません。エラーで止まるわけでもなく、ただ静かに止まったまま、約50分もの時間が過ぎていきました。
調べてみると、あらかじめ環境に入っていた実行ファイルの一部に不具合が生じており、表面上は繋がっているように見えても、実際には命令を処理できる状態になっていなかったことが分かりました。最終的には正規の経路から入れ直すことで解決したのですが、この経験は私にとって強烈な教訓となりました。
この失敗から学んだ最も大切なルールが、「本番の仕事を頼む前に、必ず小さな動作確認（スモークテスト）をする」ということです。いきなり重い作業を投げるのではなく、簡単な指示を投げて結果が返ってくるかを確かめる。それだけで、見かけ倒しの接続に騙されて貴重な時間を失う事故は防げます。
もうひとつの大きな失敗、そして今でも日常的に向き合っているのが「利用枠の枯渇」です。AIは疲れることを知りませんが、各サービスに設定された利用枠やクレジットには明確な上限があります。
実際、Antigravityの上位モデル席が枠切れを起こしたり、情報収集を担っていたHermesがクレジットの上限に達して停止したりと、枠切れによる足止めは何度も経験してきました。
特に印象深いのは、まさにこの教科書を執筆していた2026年11月2日の夜に起きた出来事です。本文執筆を一手に引き受けてくれていたCOCO（Claude）の無料メッセージ枠が、第11章を書き終えたところで上限に達してしまい、執筆作業が完全にストップしてしまったのです。
私が疲れて書けなくなったのではありません。執筆を担当していたAIの席が、枠の上限を迎えて作業できなくなったのです。画面には利用枠が回復する時刻が表示されていました。
以前の私なら「仕事が止まってしまった」と焦ったかもしれませんが、このときは違いました。慌てずに状況を記録し、回復時刻が過ぎるのを待ってから、第12章の執筆を再開しました。利用枠の上限に達することは、決して恥じるような失敗ではありません。「誰が、いつ、どこまで進んで止まったか」を記録し、回復に合わせて再開するための管理対象にすぎないのです。
作業が途中で止まったり、あるAIから別のAIへと作業をバトンタッチしたりするときには、引き継ぎのやり方に細心の注意を払う必要があります。人間同士の仕事と同じで、引き継ぎが雑だと、受け取った側は何をしていいか分からず混乱してしまうからです。
私が実践している作業の引き継ぎ記録では、必ず次の4つの項目を整理するようにしています。
1つ目は「目的」です。この作業は何のために行っているのか、最終的なゴールを明記します。 2つ目は「現在地」です。全体の工程のうち、今どこまで作業が終わっているのかを記します。 3つ目は「次の一手」です。次に担当するAIが、具体的に最初に行うべきアクションを指示します。 4つ目は「成果物の場所」です。前の作業で作成されたファイルやデータが、どこに保存されているのかを正確に伝えます。
これら4つの情報をもとに、担当するAIへは「自己完結した指示書」として依頼を渡すことが重要です。前の会話の文脈を相手が知っていると思い込んではいけません。その指示書を読めば、前後の文脈を知らなくても単独で仕事が完結できる状態にして渡す。このひと手間を惜しまないことが、連携の失敗を大きく減らしてくれます。
AIに仕事を依頼し、相手から「作業が完了しました」と返答があると、私たちはついつい安心してそのまま次の工程へ進みたくなります。しかし、ここに大きな罠があります。AIが言う「完了」と、私たちが求める品質での「完了」は、必ずしも一致しないからです。
そのため私の運用では、担当から完了の報告があっても、私自身の手で実際の成果物を検品するまでは、絶対に次の作業へ進まないというルールを徹底しています。
検品の手順はシンプルです。まず、指定した場所に本当に成果物のファイルが作られているか、その「場所の確認」を行います。次に、中身を開いて「内容が依頼の目的に合っているか」を確かめます。指示した要件が抜けていないかをチェックするのです。
もし内容に不足やズレがあれば、その場で同じ担当に修正を依頼します。問題がないことを確認できて初めて、「次の一手」へと進めます。この確認を省くと、未完成の成果物をもとに次のAIが作業を進めてしまい、後から全体をやり直す事態を招きます。
ここまでお話ししてきたような複数のAI連携を安定して回し続けるために、私の実験室で生まれた最大の成果物が「AI部隊台帳」という管理ファイルです。
AIを複数動かしていると、「今、誰がどの作業を受け持っているのか」「どの席の利用枠が残っていて、どの席が回復待ちなのか」が、頭の中だけでは把握しきれなくなります。そこで、司令塔であるMuseとともに、部隊全体の状況をひと目で把握できる台帳を作り、記録を更新しながら作業を進める運用に辿り着きました。
この台帳によって、接続状態を「接続済み」「動作確認済み」「利用可能」「作業完了」の4段階で区別できるようになりました。繋がっているだけなのか、動くことが確認できているのか、今使える状態なのか、仕事が終わったのかを混同しないことが、混乱を防ぐ最大の防壁になります。
この運用記録と管理の仕組みは、誰でも使えるように様式を一般化して本書の付録Dに正本として編纂してあります。また、引き継ぎの際に使う指示書の書式も付録Aに収録しました。これらを手元に置いておくことで、複数のAIを迷わず束ねられるようになります。
文章や図解だけでは、司令塔であるMuseがどのように他のAIへ作業を振り分け、進行を管理しているのか、その空気感を掴むのは難しいかもしれません。
そこで本書とあわせて、Museと専門AIの連携の実演動画も用意する予定です。画面上でどのような指示を出し、どのように成果物の受け渡しを行っているのか、その実際の手順をご覧いただけるようにする予定です。
収録する具体的な作業内容は未確定ですが、司令塔が状況を判断し、専門の席へとバトンを渡していく連携の様子をお届けできればと考えています。
最後に、ご自身の環境でMuseを中心としたAI連携体制を立ち上げるための再現手順を整理しておきます。
第1ステップは「自分の仕事を整理する」ことです。抱えている作業を書き出し、アイデア出し、構成案の作成、文章執筆、コード作成といった性質の異なる作業単位に分解します。
第2ステップは「仕事ごとに担当を決める」ことです。文章が得意なAI、コードが得意なツールなど、作業の性質に合わせて役割を割り振ります。最初からたくさんのAIを揃える必要はありません。まずは少数の担当から始めるのが成功のコツです。
第3ステップは「担当と利用枠の状態を確認する」ことです。ログインはできているか、当座の利用枠は残っているかを把握します。なお、私自身の契約はChatGPT PlusとGoogle AI Proで、Museは無料プランの範囲で運用しています。また、2026年11月2日にはChatGPTとCodexの利用枠が今後共通化されるという案内を受け取りました（公式情報では2026年12月から対象プランで予定されていますが、通常のInstantチャットは共通枠を消費しません）。
第4ステップは「本番の前にスモークテストを行う」ことです。簡単な挨拶や短い計算を依頼し、確実に成果物が返ってくるか確かめます。
第5ステップは「自己完結した指示書で渡す」ことです。「目的・現在地・次の一手・成果物の場所」を明記し、前後の文脈がなくても作業できる形で依頼します。
第6ステップは「成果物を確認してから次へ進む」ことです。完了報告を鵜呑みにせず、内容を検品してから次の担当へバトンを渡します。
第7ステップは「担当・利用枠・進捗を台帳に記録する」ことです。誰がどこまで進め、どの枠が停止しているかを記録に残します。
この管理方法が身につけば、AIが途中で止まっても慌てることはありません。次の実験7では、この連携体制を土台に、ブラウザ上で実際に動くゲームの制作へ挑戦していきます。