AIの指揮から、事業の設計へ。4つの構想がつながった

AIをどう組み合わせれば、もっと大きなことができるのか。

そんな問いから始めたはずが、最後には「何を作り、誰にどう届けるか」を考えていた。AIオーケストレーション、AGI Cockpit、Business OS、Distribution Machine。別々に見えていた4つの構想は、私の中では一つの思考の変化だった。

今回は、そのつながりを一枚の地図にしてみたい。

1. AIを増やすことから始まった

CodexやClaude Codeを使うと、一人でもアプリやゲームを形にできる。そこで、複数のAIに設計・実装・レビューを分担させれば、さらによいものができそうだと思った。

こうした仕事の配役や調整が、AIオーケストレーションだ。

私も試したが、一度離れた。AIを複数動かすと費用がかかり、指示を分け、進捗を見て、結果をまとめる管理も増える。その負担に見合うほど成果がよくなったのか、当時は分からなかった。

単体でもかなりのことができる。だから、人数を増やす前に「この仕事は分けた方がよいのか」を考える必要があった。

2. Cockpitを整えると、仕事の形が気になった

その後、AGI Cockpitで再挑戦した。AGIはArtificial General Intelligence（汎用人工知能）の略で、ここでは使っている環境の名前に含まれる言葉だ。

まず、AGENTS.mdなどに、全体を指揮するMasterの役割や、子へ渡す仕事、開発・確認の手順を整理した。前より扱いやすくなった感覚はあった。

でも、今度は「Masterが全部決めてよいのか」が気になった。どこで仕事を分けるか、どのモデルを使うか、何をもって完了とするか。その判断まで、毎回強いAIへ任せる必要があるのだろうか。

ここで、Harnessという考え方が役に立った。AIに渡す文脈、使える道具、作業手順、記録、検証を含む実行環境のことだ。Anthropicの長時間タスク向けHarnessの記事も、その理解を助けた。

小さな修正は一つの担当で進める。独立した調査は分担する。決まった処理はコードで動かす。私はモデル選びと一緒に、仕事を最後まで進める形を考えるようになった。

3. よく動くAIに、何を任せるのか

ただ、実行の仕組みを整えても、実行する仕事そのものが正しいとは限らない。

私が作ったJapan Dining Card（JDC）は、訪日旅行者が飲食店で食事条件や意思をカードで伝えるためのアプリだ。App Storeへ公開し、紹介動画と製品の紹介ページも用意した。それでも、思ったように人へ届かなかった。

AIで「作る」は進められた。でも、次に新機能を作るべきか、説明を直すべきか、そもそも相手の困りごとを調べるべきかは、AIの配役だけでは決まらない。

旅行者は、いつ何に困るのか。何を検索し、今の解決策に何が足りないのか。市場の声や検索、レビューを観測し、そこから仕事を選ぶ必要があった。

この経緯は、Business OSを考え始めた前編にも書いた。Cockpitを最適化する問いが、その外側にある「何のために動かすか」へ広がった。

4. Business OSで、仕事同士をつなぐ

市場を観測し、根拠を集め、取り組む課題を選ぶ。製品を作り、届け、利用や反応から学ぶ。この一周をBusiness OSと呼ぶことにした。

ここでのOSはOperating System。事業を進める情報と判断を、基本ソフトのようにつなぐ構想だ。

例えば、困っている人の投稿が見つかった。それは観測した根拠になる。「同じ場面で困る人が多いのではないか」は、そこからの解釈だ。そして「この機能を作ろう」は判断になる。この3つを混ぜずに、次の仕事へ渡したい。

Cockpitとの役割も整理できた。Business OSは「何を・なぜ・いつ行うか」。AGI Cockpitは「どう・何で・誰が実行するか」。前者で選んだ仕事を、目的や完了条件とともに後者へ渡す。結果は、次の事業判断へ戻す。

これで、市場調査、開発、発信が一つにつながった感覚があった。ところが、地図を眺め直すと、まだ一か所だけ粗かった。

5. 最初の10人は、どこから来る？

製品については、対象、機能、画面、実装まで細かく考えている。一方、届け方は「YouTube」「SNS」「広告」という箱で終わっていた。

Productは設計しているのに、Distributionは設計していなかった。

対象が「訪日旅行者」でも、最初の一人は勝手には来ない。その人は旅行前なのか、旅行中なのか。何を探し、誰の説明を信用するのか。そして、最初の10人はどこから来るのか。

この問いから、ProductとDistributionを同時に設計する考えへ進んだ。Business Thesis、つまり「誰のどんな問題に、どんな価値を届けるか」という事業仮説から、二つのBrief（設計の要約）を作る。

市場の困りごとは、製品の材料だけではない。相手が使う言葉や、助けを探している場所も教えてくれる。ただし、公開投稿を見つけたことは、その人へ連絡してよいという同意にはならない。

ストア、検索、Creator、Communityなど、経路も評価する。全部を使うのではなく、相手と製品に合うものを選ぶ。この設計を繰り返し、結果から直す仕組みがDistribution Machineだ。詳しい経路はDistributionの記事にまとめた。

6. 作る・届ける・学ぶを、同じ一周にする

Distribution Machineでは、ダウンロードの先も考える。最初に価値を感じること、必要な場面でまた使うこと、紹介したくなること。JDCなら、まずカードへ迷わず進み、店員に見せる準備ができるかが、確かめる問いの一つになる。

4つの構想は、発見した順番では一本の線になった。ただ、運用の構造では、DistributionはBusiness OSの中にある。そこで選んだ仕事をCockpitへ渡し、実行した結果を次の判断へ戻す。

これは、すでに自動で事業を育てられたという成果報告ではない。今あるのは、実装と検証へ持ち込むための地図だ。届け方を整えても製品が問題に合わなければ選ばれないし、困りごとの声だけで市場規模や採算は分からない。

だから次は、JDCの一つの場面に絞って、説明と接点を一つずつ考え、反応から何を変えるかを確かめたい。最初から大きな仕組みを全部動かす必要はない。

AIをうまく動かしたい、から始まった問いは、意味のある仕事を選び、作った価値が届くところまでつなぎたい、へ変わった。

作る力が増えた今、その先まで設計する。この4つの構想がつながって、私にはようやく、その一周が見えてきた。

関連する詳しい記事：Business OS前編／Business OS後編／Distribution Machine