はじめに こんにちは、Insight Edge アジャイル開発チームの山崎です。 マルチエージェントシステムを設計する際、多くの設計判断に直面します。議論はシングルステップで十分か、複数ステップに分割すべきか？各ステップに誰を参加させるべきか？プロンプトはどこまで詳細に書くべきか？ 今回の記事では、Google ADK + Geminiを用いて、スタートアップの新規事業立案という具体的な意思決定の事例でマルチエージェントシステムを実際に構築し、議論の論点、議論の進め方、議論するメンバーなどを変化させながら、3つの異なるアプローチを比較検証しました。その結果、以下の知見を得ました（詳細は 考察 セクションを参照）。 議論メンバーの非対称性設計 : 楽観派と批判派のバランスが議論品質を左右する 細かいステップ分割 : 論点を細分化することで議論が効率化し、成果物精度が向上する プロンプトチューニングのPDCA : システムの価値は「仕組み」ではなく「プロンプト精度」にある 例えば、楽観的なCEO・CMOによる発散的なブレインストーミングと、批判的なCFOによる財務検証を別ステップに分離することで、アイディアの多様性と実現可能性を両立できました。また、議論をステップ単位で細分化することで、プロンプトの改善→結果確認→再改善という高速なPDCAが可能となり、成果物の精度が大きく向上しました。これらの知見の詳細は 考察 セクションで解説します。 ※本記事は、マルチエージェントシステムの技術検証を目的とした実験的な取り組みの報告です。記事内で紹介するアプリケーションおよび事業アイディアの内容（レシピサービス、クラフトビールコーチング、デジタル終活サービス、希少動植物飼育ガイドなど）は、全て検証用のサンプル出力であり、当社の正式なサービス提供、事業計画、または推奨を意味するものではありません。また、記載されている市場規模や売上計画などの数値は検証目的の仮想データです。 目次 はじめに 目次 背景：マルチエージェントとは 課題設定：スタートアップの新規事業立案 検証用アプリケーションについて アプリケーション要件 システム構成 アプリケーション環境 議論設定ファイル 論点定義 成果物定義 メンバー定義 ステップ定義 アプローチ別検証 アプローチ１：シングルステップ 議論トポロジー（１） 議論の結果（１） 議論の良い点（１） 議論の課題（１） アプローチ２：ステップ分割定義 議論トポロジー（２） 議論の結果（２） 議論の良い点（２） 議論の課題（２） アプローチ３：ステップ別詳細定義 議論の結果（３） 議論の良い点（３） 議論の課題（３） 考察 1. 議論の登場メンバーの非対称性設計 2. 議論の論点の細かい分割 3. システムの価値の所在が仕組みからプロンプトに移行 4. 議論およびアウトプットの品質を上げるPDCA 5. トップダウン的な議論分割とボトムアップ的な統合 6. エンドユーザーや顧客のニーズに合わせたDIY的システムというパラダイム 今後の展望 1. ファシリテーターの導入 2. 議論トポロジーの多様化 3. エンドユーザー独自の制約定義 4. 議論の評価基準の設計 まとめ 背景：マルチエージェントとは マルチエージェントとは、複数のAIエージェントがそれぞれ役割を持ち、協調・分担・相互作用しながら問題を解決する仕組みのことです。 各エージェントは以下のような特性を持ちます。 自律性 ：人間の指示なしに判断・行動する 社会性 ：他のエージェントと通信・交渉する 反応性 ：環境の変化に応じて行動を変える 能動性 ：目的達成のために自発的に動く 例えばChatGPTのようなエージェントと対話形式を取るものは、シングルエージェントと呼ばれます。シングルエージェントの自己検証は内部的ですが、マルチエージェントは構造的に外部から反証・再評価を組み込める点が大きく異なります。 マルチエージェントやAIエージェントの時代背景、歴史的な発展については、「 世界は新たな時代を迎えようとしている 」もご参照ください。 課題設定：スタートアップの新規事業立案 多様な役割を持つエージェントによって構成されるマルチエージェントは、多様な観点を取り入れる必要がある複雑な問題と相性が良いと言われています。 また、シングルエージェントでは解決が難しい論理矛盾、ハルシネーション、認知バイアスに対しても、他の役割を担うエージェントのチェックが入ることで、構造的に議論の品質が向上することが見込めます。 本記事では、複雑な問題の具体例としてスタートアップの新規事業立案を考えたいと思います。 スタートアップというと、シードフェーズやアーリーフェーズからエンジェル投資家やベンチャーキャピタル投資家の投資を受け、バイアウトやIPOなどのイグジットを狙う企業というイメージが強いかもしれません。しかし本記事では、自由に経営陣が意思決定できる小規模かつ柔軟なチームと定義させていただきます（もちろん、この定義やゴールは設計次第で柔軟に変更可能です）。 スタートアップの新規事業構想のディスカッションに登場するメンバーは以下の通りです。 メンバー 役割 CEO チーム全体の議論を統合し、各メンバーの意見を踏まえて最終的な判断を下す役割を担う。 CMO 市場動向や顧客ニーズの視点からアイディアを提供したり、評価する役割を担う。 CFO 財務的な観点からアイディアの実現性と実現可能性を評価する役割を担う。 CTO 技術的な観点からアイディアの実現可能性を評価する役割を担う。 経営コンサルタント 経営メンバーが提示した事業アイディアに対して、意図的に反論・反証を行う役割を担う。 検証用アプリケーションについて 本記事では、マルチエージェントで議論を行う検証用アプリケーションを実装し、同じ論点においていくつかのアプローチによる結果を検証しました。ここでは、その要件、構成などを説明します。 アプリケーション要件 検証用の本アプリケーションは以下のシステム要件を備えています。 1. 議論の成果物のフォーマットを自由に定義できること 2. 議論の論点を自由に定義できること 3. 議論に登場するメンバーを自由に定義できること 4. 議論の進め方として複数のステップに分割することができ、それぞれ自由に定義できること 5. 各ステップの終了時には成果物の品質チェックを行うこと 6. 各ステップの成果物は次のステップに引き継げるようにすること 議論に登場するメンバーにはプロンプトを通じて、どのような役割を持つのか、どのような行動指針があるかを指示できます。また、必要に応じてGoogle検索などの外部ツール（Function Calling）を利用可能にできます。 各ステップの定義では、そのステップに参加するメンバーや発言順序を定義できます。ステップ独自の挙動についてはプロンプトで制御でき、ステップ内の発言回数を round として定義できます。 システム構成 本記事で実装したアプリケーションの構成図は以下の通りです。 図：本アプリケーションのシステム構成図（著者作成） 本アプリケーションのエンドユーザーは、事前に定義された議論設定ファイルの中から実行したい議論を選択します。 選択された議論設定ファイルの構成に応じて、本アプリケーションのコンポーネントが展開され、議論が開始されます。 各ステップ毎にラウンド数分の発言がメンバー内で繰り返され、結論と成果物を生成します。その成果物の品質チェックが行われ、問題がなければ次のステップに進みます。問題があれば議論は差し戻され、これまでの議論内容が引き継がれて再度議論が行われます。 最終的に全てのステップの議論が終了すると、全体の結論が生成され、議論レポートが Markdown形式で出力されます。 アプリケーション環境 ソフトウェア バージョン Python v3.12.11 google-adk v1.25.1 google-genai v1.64.0 LLMモデル gemini-2.5-flash google-adk （Agent Development Kit）は、AIエージェントの開発・デプロイのためのフレームワークです。マルチエージェントアーキテクチャやワークフローの構築を担います。一方、 google-genai は Gemini APIへのアクセスを提供するPython SDKで、LLMとの通信やFunction Callingの実行基盤として google-adk の内部で利用されています。 今回の検証では1回の議論で数十回のAPI呼び出しが発生します。そのため、レイテンシとコストを抑えつつ十分な推論品質を確保できる gemini-2.5-flash を選択しました。 gemini-2.5-pro と比較して応答速度が速く、API費用も低いため、試行錯誤を繰り返すPDCAサイクルに適していると判断しました。 議論設定ファイル 議論設定ファイルは YAML形式で記述され、以下のフォーマットとなっています。 id : 議論に紐づくユニークなID name : 議論の名称 description : 議論の説明文 topic : 議論の論点 output : 議論の成果物 members : 参加メンバー steps : 議論のステップ 以下、各項目の詳細について説明します。 論点定義 topic 項目により、議論の具体的な論点を定義することが出来ます。 topic : | * AIを活用した消費者向けのソリューションにおける具体的な事業アイディアを出してください。 * 最初に事業アイディアを10個程度出し、最終的に1~3個程度に絞ってください。 * **法人向けソリューションではないことに注意** * **抽象的な表現はNGです** 成果物定義 output 項目により、議論の具体的な成果物を指定することができます。ここで指定された成果物が、最終的に生成されるレポートに出力されます。 output : | 事業アイディアのリスト。事業アイディアは以下の要素を含む。 - アイディアの概要：例) AIを活用したオンライン学習プラットフォーム - ターゲット顧客：例) 中高生とその保護者 - 想定する顧客課題：例) 学習の個別最適化が難しい、モチベーションの維持が困難 - 想定する市場規模：例) 100億円 ... メンバー定義 members 項目で、議論に参加する具体的なメンバーを定義することが出来ます。 各メンバーの挙動は、 prompt で記述され、具体的にはそのメンバーの役割や行動指針を指定しました。 tools 項目で、事前に実装されている外部ツールをAIエージェントに渡すことができます。今回の検証では、議論中に好きなキーワードでGoogle検索を実行できる google_search() にアクセスできるようにしています。 members : - id : ceo name : "CEO" prompt : | あなたはスタートアップ企業のCEOです。 チーム全体の議論を統合し、各専門家の意見を踏まえて最終的な判断を下す役割を担います。 行動指針 : - 各メンバーの専門的な意見を尊重しつつ、全体最適の視点で意思決定を行う - 議論が発散した場合は論点を整理し、結論に導く - ビジョンと実現可能性のバランスを常に意識する tools : [ google_search ] ステップ定義 steps 項目にて、議論の具体的なステップを定義することが出来ます。 ステップでは、 members 項目 にて、該当ステップに参加するメンバーと発言順序を定義することが出来ます。 output 項目は、該当ステップの成果物を定義するもので、生成された成果物は次のステップの入力値として扱われます。 rounds は、そのステップの議論における発言回数を表します。指定された発言回数分の議論を重ねた後、成果物の品質が検証され、品質が不合格となった場合、 fallback で定めたステップに差し戻しとなります。 steps : - id : step1 name : "事業アイディアのブレインストーミング" members : [ ceo, cmo ] description : "楽観的に初期の事業アイディアをブレインストーミングする" output : | 事業アイディアのリスト。事業アイディアは以下の要素を含む。 - アイディアの概要：例) AIを活用したオンライン学習プラットフォーム - ターゲット顧客：例) 中高生とその保護者 - 想定する顧客課題：例) 学習の個別最適化が難しい、モチベーションの維持が困難 - 想定する市場規模：例) 100億円 ... prompt : | - CEOとCMOは、自由な発想でアイディアをたくさん出すことを優先し、批判は控えること（質よりも量を優先）。 rounds : 8 fallback : step1 アプローチ別検証 本記事では、以下の3つのアプローチを検証しました。各アプローチの概要と結果は以下の通りです。 指標 アプローチ1 アプローチ2 アプローチ3 方式 シングルステップ ステップ分割定義 ステップ別詳細定義 ステップ数 1 5 5（個別実行） 実行時間 14分01秒 36分39秒 42分35秒（合計） 出力アイディア数 1 4 3 成果物精度 中 中〜高 高 PDCA容易性 低 低 高 以下、各アプローチの詳細を説明します。 アプローチ１：シングルステップ 最初のアプローチでは、論点と成果物を詳細に定義し、ステップ分割を敢えてせずに全ての登場人物を同時に議論させました。すなわち、ブレインストーミングから売上・技術・マーケティング検証、反証検証まで全ての議題を1ステップに集約し、5名全員が参加する構成です。 論点は、議論設定ファイルにて以下のように定義しました。いくつか今回の検証における設定や制約において説明します。 事業アイディアの条件としてはAIを活用したものに限定し、法人向けのソリューションではなく、 消費者向けのソリューション としました。これは、消費者向けサービスと設定した方が初期のブレインストーミングで様々なアイディアが出ることが期待され、その多様さを結果に反映したいと考えたからです。 対象とする市場についてもニッチ市場に限定することで多様なアイディアが出るように設定しました。 一方で、売上計画についてはニッチ市場戦略である以上、大きなスケール成長ではなく、より堅実で緩やかな成長を想定しました。 論点・成果物の詳細定義（クリックで展開） # 議題 * AIを活用した消費者向けのソリューションにおける具体的な事業アイディアを出してください。 * 最初に事業アイディアを10個程度出し、最終的に1~3個程度に絞ってください。 * **法人向けソリューションではないことに注意** * **抽象的な表現はNGです** ## 初年度のPLについて * 各事業アイディアに対して、以下の２パターンの初年度のPL（収益決算書）を作成し、`output`のフォーマットに従って成果物を作成してください。 * 標準シナリオ * 悲観シナリオ * PLの構成としては以下のような形を想定していますが、必要に応じて適宜修正してください。 　``` 売上: 1200万円 変動費: 印刷原価: 5万円 × 24 = 120万円 API費: 年間30万円 固定費: エンジニア1人×3ヶ月: 150万円 代表営業50%稼働: 300万円換算 CMO 30%稼働: 200万円換算 その他: 50万円 営業利益: 　``` ## 技術的観点について * 既存の事業アイディア一覧に対して、CTOが中心となって技術面からレビューを行い、新たに技術視点の差別化戦略、技術要件、開発期間見積もり、技術的リスクを作成し、`output`のフォーマットに従って成果物を作成してください。 * 技術視点の差別化戦略：この事業アイディアを技術面でどのように差別化するかを記述してください（書き方、フォーマットについては後述） * 技術要件：この事業アイディアを実現するために必要な技術要件を具体的に記述してください。例）大規模言語モデルのAPI、リアルタイム音声認識技術、等 * 開発期間見積もり：この事業アイディアを実現するために必要な開発期間の見積もりを記述してください。例）6ヶ月、1年、等 * 技術的リスク：この事業アイディアに関連する技術的なリスクを記述してください。例）大規模言語モデルのAPIコストが高すぎる可能性、リアルタイム音声認識の精度が不十分な可能性、等 ## マーケティング観点について * 既存の事業アイディア一覧に対して、CMOが中心となってマーケティング観点からレビューを行い、完成度を高め、`output`のフォーマットに従って成果物を作成してください。 * 既存の事業アイディアの要素をレビューし、必要に応じて修正してください。特に以下の項目を重点的にレビューしてください。 * 想定する市場規模：現在の仮定の根拠を検証し、修正が必要であれば修正してください。 * 既存の要素にない、以下の要素を作成し、新たに要素として成果物に追加してください。 * マーケティング手法：売上計画、PL等を実現するための主要なマーケティング手法を具体的に最大３つ記述してください。 * マーケティング計画：各マーケティング手法毎にその計画を記述してください。例）1年目はSNS広告で認知獲得、2年目はインフルエンサーマーケティングでユーザー獲得、等 * マーケティング計画には、各施策の目的、ターゲット、実施内容、KPIを含めてください。 ## 反証検証 * 最後に、事業アイディアの最終的な検証を行い、`output`のフォーマットに従って成果物を作成してください。 * 主要リスク：この事業アイディアに関連する主要なリスクを記述してください。例）市場の反応が冷淡であるリスク、技術的な実現が困難であるリスク、等 * 反論とそれに対する対策：経営コンサルタントが提示した反論に対して、それを克服するための対策を記述してください。例）市場の反応が冷淡であるリスクに対する対策として、初期ユーザーからのフィードバックを迅速に取り入れてサービス改善を行う、等 * 最終的な推奨アイディアの順位付け：CEOが中心となって、最終的に推奨する事業アイディアの順位付けを行い、その理由も含めて記述してください。例）事業アイディア1は市場のニーズが高く、技術的にも実現可能であるため最も推奨される、等 # 制約 ## 市場に関する制約 * 対象マーケットについて * ニッチ市場のみを対象とする。**決して、大衆を狙った市場をターゲットにしないこと**。 * 大衆に向けた汎用性の高いプロダクト・パッケージ販売はさけてください。 * 資本力が弱いため、マスプロダクトを開発して、ユーザーの囲い込みを行う資本力勝負の戦い方は不利です。 * ターゲット顧客のニーズをしっかりと捉え、少人数でも顧客のエンゲージメントを高めることを優先し、徐々に拡大する戦略で進めたいです。 * ターゲット顧客について * ターゲット顧客は、個人であれ法人であれ、**最終消費者であること**が必須です。 * 法人向けのソリューションは、顧客が少なく、1社あたりの売上が大きくなりがちですが、顧客獲得の難易度が高く、営業リソースも限られているため、現時点では避けるべきです。 * 顧客課題について * 顧客課題は、**顧客が日常的に感じているものであること**が重要です。 * 顧客が感じていない課題を無理やり作り出すのは避けてください。顧客のニーズをしっかりと捉えることが重要です。 * 顧客課題は、**解決されていないものであること**が重要です。既に多くの競合が解決している課題は避けてください（それではニッチ市場戦略を取っている意味がありません）。 * 市場規模(TAM)について * 市場規模は、**ニッチ市場であっても、十分な売上が見込めるものであること**が重要です。 * 例えば、数千人程度の顧客がいて、1人あたり年間1万円程度の売上が見込める市場であれば、十分に魅力的な市場と言えます。 * TAMの算出は、トップダウンでもボトムアップでもどちらでも構いませんが、CMOを中心として、前提を明確にして、合理的な根拠に基づいて算出してください。 ## 提供するソリューションに関する制約 * ソリューションは、**AIを活用したものであること**が必須です。 * ソリューションは、**ターゲット顧客の課題を解決するものであること**が重要です。顧客のニーズをしっかりと捉え、顧客が求める価値を提供することが重要です。 ## 競合に関する制約 * 既存の競合サービスの調査は、CMOが中心に行ってください。Google検索ツールを活用して、類似のサービスがないかを調査してください。 * 既存の競合サービスは、**同じ顧客課題を解決するものであること**が重要です。異なる課題を解決するサービスは競合とは言えません。 * 競合サービスが存在する場合は、その競合サービスに関する主要なURLを１つ調べ、さらに強みと弱みを分析し、自社ではどのように差別化するべきかを考えてください。 * 競合サービスが複数ある場合、最大３つの競合サービスを調査してください（強力なサービス順）。 ## 売上計画に関する制約 * 売上計画では以下の点を考慮してください。ただし、売上計画の数値が出せない場合は、仮置きして、前提を明示してください。 * 年間単価 * 必要ユーザー数 * 初年度のPL * 年度別の売上として、以下のラインは見込めること。 * 初年度：ゼロを許容 * 1年目：1000万円/年 * 3年目：3000万円/年 * 5年目：1億円/年 ## 自社に関する制約 * 会社のリソースについて * 会社にはエンジニアのバックグラウンドを持つ人間が数名おり、営業やマーケティングのリソースは少ない。 * 営業活動は代表が自ら行う。 成果物は以下のように定義しました。 事業アイディアのリスト。事業アイディアは以下の要素を含む。 - アイディアの概要：例) AIを活用したオンライン学習プラットフォーム - ターゲット顧客：例) 中高生とその保護者 - 想定する顧客課題：例) 学習の個別最適化が難しい、モチベーションの維持が困難 - 想定する市場規模：例) 100億円 - 提供するソリューション概要：例) AIが生徒の理解度や興味に合わせて最適な学習コンテンツを提供し、ゲーム要素でモチベーションを維持するオンラインプラットフォーム - 既存の競合サービス：例) 学習塾、予備校、等 - この先５年間の売上計画：例) 1年目: 1000万円、2年目: 5000万円、3年目: 2億円、4年目: 10億円、5年目: 50億円 - 初年度PL（標準シナリオ）：CFOを中心に作成 - 初年度PL（悲観シナリオ）：CFOを中心に作成 - ２年目以降の資金調達計画：例) 2年目にエンジェル投資家から500万円、銀行からの融資で500万円、3年目にVCから1億円、等 - 技術視点の差別化戦略：CTOを中心に議論をして作成 - 技術要件：CTOを中心に作成 - 開発期間見積もり：CTOを中心に作成 - 技術的リスク：CTOを中心に作成 - マーケティング手法：CMOを中心に議論して作成 - マーケティング計画：CMOを中心に議論して作成 - 主要リスク：経営コンサルタントを中心に議論して作成 - 反論とそれに対する対策：経営コンサルタントを中心に議論して作成 - 最終的な推奨アイディアの順位付け：CEOを中心に議論して作成 ステップの定義では、上記の論点と成果物を１ステップで全登場人物に議論させています。 これらの詳細な設定ファイルを参照したい方はこちらを参照ください → startup_v1.yaml 議論トポロジー（１） 上記の通り、アプローチ１のステップは１つしか定義していませんが、その登場人物間の発言のトポロジーを可視化すると以下のようになります。 CEOから発言を開始し、全ての登場人物が順に発言をし、ラウンド数分の発言が行われた時点でこのステップの議論が終了となります。 図：アプローチ１の議論トポロジー（著者作成） 議論の結果（１） 上記の設定で議論させたところ、所要時間14分1秒の議論が行われ、「AIを活用した特定の食事制限・手持ち食材向けレシピ生成サービス」というアイディアが最有力となりました。 このサービスは、「複数の食物アレルギーを持つお子さんを持つ親御さん、特定の疾患（例：腎臓病、糖尿病）により厳格な食事療法が必要な個人」が、複雑な食事制限下での献立考案が困難であることや、手持ち食材でのレシピ探しが難しい、食事のマンネリ化すること、等を課題と捉え、個人の食事制限、リアルタイムの手持ち食材、嗜好をAIが分析し、パーソナライズされたレシピを提案する、とのことです。 実際に生成された議論レポートは長文となるためここでは割愛しますが、参照したい方はこちらを参照ください → startup_v1_20260228_235325.md 議論の良い点（１） 比較的、成果物を細かく規定し、論点においても様々な制約を細かに記述したため、それなりに期待するアウトプットには到達しています。 例えば、成果物では以下の点を詳細に規定している。 初年度のPLのフォーマット 技術的観点の成果の要素 マーケティング観点の成果の要素 反証検証の方法 また、制約についても以下の点を詳細に規定している。 市場に関する制約：特にニッチ市場の特化 ターゲット顧客の制約 顧客課題の制約 提供するソリューションの制約 競合に関する制約 売上計画に関する制約 自社に関する制約：主にリソースや得意領域の記述 議論の課題（１） 主に以下の点が課題点として考えられます。 1. 複数のアイディアが出たが、１つ目のアイディアの深堀りに議論が集中したこと 2. 個人が自身の役割だけを主張し議論が停滞してしまったこと 3. 成果物の精度が低さ（市場規模、顧客獲得モデル、MVP定義） １つ目の課題は、最初にブレインストーミングの発散型ステップを設け、その後のステップで評価/選定といった収束型ステップを設けることで解決されることが期待されます。 初期のアイディア出しのフェーズで、すぐにCFOの売上検証という批判的な議論が開始してしまったことで、議論が収束してしまいました。２つ目の課題は、各ステップにおいて、推進派と保守派の良いバランスで適任者を選定することで解消されそうです。 ３つ目の課題については、議論が効率的に進まなかったことにより、これらの論点で十分な時間が割かれなかったことが原因です。これも適切なステップ分割と効率的な議論で改善しそうです。 それでは、複数のステップに分割して、再度検証してみます。 アプローチ２：ステップ分割定義 本アプローチでは、新規事業構想の議論を複数のステップに分割し、かつ、各ステップに参加する人物を調整しながら議論の精度向上を試みます。 議論の論点はアプローチ１と同じにしました。 ステップは以下の流れとなるようにし、各ステップの参加メンバーも限定するように設定ファイルに記述しました。 ステップ 参加メンバー（発言順） 概要 1. 事業アイディアのブレインストーミング CEO、CMO 初期の事業アイディア出し 2. 売上検証 CFO、CEO、CMO 各事業アイディアの売上計画、PLの修正と検証 3. 技術検証 CTO、CEO、CMO、CFO 各事業アイディアの技術的検証と追記 4. マーケティング検証 CMO、CEO、CTO、CFO 各事業アイディアのマーケティング的検証と追記 5. 反証検証 経営コンサルタント、CEO、CMO、CTO、CFO 全ての仮説に対する反証に耐えうるか検証 これらの詳細な設定ファイルを参照したい方はこちらを参照ください → startup_v2.yaml 議論トポロジー（２） アプローチ２は複数のステップにより構成され、その登場人物間の発言のトポロジーを可視化すると以下のようになります。 図：アプローチ２の議論トポロジー（著者作成） 議論の結果（２） マルチステップでマルチエージェントに議論させたところ、所要時間36分39秒の議論が行われ、「AIクラフトビール自家醸造パーソナルコーチング」というアイディアが最有力となりました。 このサービスは、「クラフトビール自家醸造の上級者・中級者」が求めるような「微細な味覚プロファイルの深層学習」や「個人の深いこだわりに基づいたパーソナルコーチング」が不足しているという課題に対して、ユーザーの入力データ（既存ビール評価、自由記述、醸造結果）からパターンを抽出し、「あなたのこの好みの背景には、このような味覚の傾向がある」といった洞察を提供し、「ユーザーの味覚探求を深めるための強力な補助線」となる役割を果たす、とのことです。 実際に生成された議論レポートは長文となるためここでは割愛しますが、参照したい方はこちらを参照ください → startup_v2_20260301_003355.md 議論の良い点（２） 主に以下の点が良い点として考えられます。 事業アイディアをすぐ１つに絞らず、最後まで4案が評価対象として残っていること 議論のステップが明確に構造化されていること 品質チェック機構が機能していること 成果物の一部精度向上（MVPの具体化） アプローチ１の課題の多くが、ステップ分割をより細かく定義し、参加メンバーを調整することで改善されていることが確認できました。 また、細かくステップが分割されていることにより、品質チェックもより評価しやすくなり、議論の差し戻しが発生しやすくなり、議論の精度が向上したことが伺えます。 結果的に議論が効率化され、成果物の各項目において議論する時間が増えたことでアプローチ１よりも精度が向上していることが伺えました。 議論の課題（２） 主に以下の点が課題として挙げられます。 成果物として一部のデータに欠損が生まれていること 市場規模（TAM）の前提がブレている点 TAMと売上計画の整合性不足 成長メカニズムが未設計 全てのステップを連結させて一気に結論を出そうとしているために、全ての議論が終了するのに40分弱の時間がかかってしまいました。これでは、フィードバックを得るまでに時間も、フィードバック対象の粒度も粗い状況となってしまいます。 アプローチ１の課題は大きく改善されましたが、ここで挙げた課題を一つ一つ解決していくには、もう少し細かい粒度の議論で、フィードバックを受けながら、プロンプトを試行錯誤しながら微調整する必要性を認識しました。 それでは、各ステップ別に議論を終了し、短いスパンでフィードバックを得ながら、プロンプトや設定を修正してきたいと思います。 アプローチ３：ステップ別詳細定義 アプローチ２でもステップ分割を行いましたが、各ステップの粒度でプロンプトのチューニングを行いたくなったため、各ステップを議論として定義し、議論にはステップを１つしか含まない構成へと変更しました。 このような変更をすることで、議論のフィードバックを短時間で得られ、議論のインプット担っていた設定（プロンプト）を微調整しながら、アウトプットの精度を変化させる高速なPDCAが可能となります。 各議論のプロンプトはベースはアプローチ２と同じですが、生成される成果物を確認しながら、プロンプトを調整しました。また、登場人物、トポロジーに関してはアプローチ２と同じにしています。 これらの詳細な設定ファイルを参照したい方はこちらを参照ください。 startup_v3.1_brain-storming.yaml startup_v3.2_financial-review.yaml startup_v3.3_technical-review.yaml startup_v3.4_marketing-review.yaml startup_v3.5_verification.yaml 議論の結果（３） 議論にかかった時間は以下の通りです。 ステップ名 所要時間 1. 事業アイディアのブレインストーミング 4分25秒 2. 売上観点での検証 8分47秒 3. 技術観点での検証 8分18秒 4. マーケティング観点での検証 4分16秒 5. 全体プランへの反証検証 16分49秒 複数の議論を重ねたところ、最終的には以下の３つの事業アイディアが有力なものとなりました。 ニッチ書籍特化型AI読書支援サービス - 特定ジャンルの読書家向けに、AIレコメンド・読書アシスタント・理解度分析を提供 AIデジタル終活支援サービス - デジタル資産の整理・管理・家族への引き継ぎをAIで支援 希少動植物AI飼育・栽培ガイド - 希少種の画像識別・パーソナル飼育ガイド・病害虫診断を提供 各事業アイディアの詳細（クリックで展開） １つ目のサービスは、「特定のニッチな書籍ジャンルに深く没頭したい読書家」が自分に真に合った、質の高いニッチな本が見つけにくいことや、難解な本で挫折しやすく、専門的な解説や背景知識の助けが欲しいこと、などを課題と捉え、以下のソリューションを提供します。 AIレコメンドエンジン ：読書履歴、感想、学習目標に基づき、ニッチな書籍を高精度で推薦。 AIチャットアシスタント ：読書中に専門用語の解説、背景知識提供、著者思想の深掘り、読書内容に関する議論をサポート。 AI読書進捗・理解度分析 ：読書速度や理解度をAIが分析し、最適な読書ペースやアプローチを提案。 ２つ目のサービスは、「50代以上のデジタルサービス利用経験が豊富で、自身のデジタル資産の行方や、家族に負担をかけたくないという意識を持つ層」が、死後のデジタルデータ（アカウント、写真、契約情報など）の整理方法が分からないことや、家族にパスワードや重要な情報を伝えることへの心理的抵抗やセキュリティ上の懸念、などを課題と捉え、以下のソリューションを提供します。 AIアカウントスキャン＆提案 ：連携したメールやブラウザ履歴から利用中のデジタルサービスをAIが特定し、利用状況に応じて整理（継続、削除、引き継ぎ）を提案。 安全なデジタル遺産管理 ：暗号化されたクラウド上でパスワードや重要情報を一元管理。生前の意思に基づき、指定した時期や条件で家族に情報開示する仕組み。 AIチャットアシスタント ：デジタル終活に関する疑問、法的な相談（提携専門家への繋ぎ込み）、データのバックアップ方法などをAIがサポート。 エンディングノート連携 ：デジタル資産だけでなく、生前の想いやメッセージを記録する機能。 ３つ目のサービスは、「市販の一般的な情報では物足りず、特定の希少種や専門性の高い動植物に深い愛情と知識欲を持つ個人」をターゲットとしています。 この層は、希少種の正確な識別が難しいことや、専門情報が書籍や特定のコミュニティに限定されアクセスしにくいこと、病気や異常発生時の原因特定と対処法が分からないこと、といった課題を抱えています。以下のソリューションでこれらの課題を解決します。 高精度AI画像識別 ：ユーザーがアップロードした写真から希少な動植物の種を高精度で識別。 パーソナル飼育/栽培ガイド ：識別された種に基づいて、温度、湿度、栄養、光量、水質など、個体や環境に合わせた最適な飼育/栽培プロトコルをAIが提案。 AI病害虫診断＆対策 ：画像認識で病害虫の兆候を早期に発見し、具体的な対策方法をアドバイス。 AIチャットQ&A ：飼育・栽培に関するあらゆる質問にAIがリアルタイムで回答。 実際に生成された議論レポートは長文となるためここでは割愛しますが、参照したい方はこちらを参照ください 。 startup_v3.1_brain-storming_20260228_195019.md startup_v3.2_financial-review_20260228_204333.md startup_v3.3_technical-review_20260228_215418.md startup_v3.4_marketing-review_20260228_223255.md startup_v3.5_verification_20260228_232437.md 議論の良い点（３） 主に以下の点が良い点として考えられます。 議論を分割して細かく区切ることで、PDCAを回すことで成果物の精度を上げることができること 差別化戦略の論点が具体化している点 技術的リスクが明確に列挙されている点 MVP設計が現実的になっている点 成果物のフォーマットの安定と精度向上 アプローチ２のプロンプトをベースにしましたが、そこから何度もプロンプトを調整しました。 成果物が得られた上で、過不足があればプロンプトを調整して何度も議論をさせることにより、差別化戦略の論点の明記、技術的リスクの論点の明記、MVP設計の論点の明記など、事細かにプロンプトに記述することでアウトプットの品質が向上したことが分かります。 議論の課題（３） ただし、まだ以下の点が課題として挙げられます。 売上計画のリアリティ検証が弱い点 TAMの精度が依然として粗い点 データ取得戦略が未設定である点 法的・倫理的リスクが高い点 ここで挙げられた課題は全てプロンプトを修正することで潰せる点ばかりです。アプローチ３のように議論を細分化するほど、論点や制約はシャープになるため、さらに試行錯誤しながらプロンプトを改善することで、より満足のいく成果物の精度を期待することが出来るでしょう。 考察 これまで、以下の順でいくつかのアプローチを検証し、マルチエージェントシステムのそのインプットとアウトプットを見てきました。 アプローチ１：単純なワンステップでの議論 アプローチ２：複数ステップに分割した一気通貫の議論 アプローチ３：複数ステップ毎に試行錯誤しながらの議論 これらの検証から個人的に得られた考察は以下の６点に集約されます。 1. 議論の登場メンバーの非対称性設計 2. 議論の論点の細かい分割 3. システムの価値の所在が仕組みからプロンプトに移行 4. 議論およびアウトプットの品質を上げるPDCA 5. トップダウン的な議論分割とボトムアップ的な統合 6. エンドユーザーや顧客のニーズに合わせたDIY的システムというパラダイム 1. 議論の登場メンバーの非対称性設計 議論に登場するメンバーの特性には非対称性を持たせることが重要と考えられます。 今回の議論では、役割が異なるCEO、CMO、CFO、CTO、経営コンサルタントを定義しました。 これらのメンバーには、それぞれの役割や行動指針が定義できますが、あえてその方向性や価値基準に多様性を持たせることで、お互いの視点の衝突やバイアス相殺を促すようにしました。実際にCEOやCMOは楽観的なアイディアマンとして定義してましたが、物事を定量的に批判的に捉えるCFOからは、詰めの甘いプランに厳しいフィードバックがかかり、売上計画の精度を向上する議論が見られました。 2. 議論の論点の細かい分割 今回の議論では、いきなり事業アイディアを成果物としてアウトプットするのではなく、以下のステップへと分割しました。 1. 事業アイディアのブレインストーミング 2. 売上観点での検証 3. 技術観点での検証 4. マーケティング観点での検証 5. 全体プランへの反証検証 議論を細かい粒度に分割することで議論が効率的に進み、結果としてアウトプットの精度が向上する様子が見られました。 また、各議論ではあえて参加させるメンバーを限定させることで、不必要な意見の衝突を減らし、そのステップでの議論を加速させるなどの調整も大切だと思います。例えば、ブレインストーミングのような発散フェーズでは楽観派のCEOとCMOに限定することで、多くのアイディアが生まれる様子が観測できました。 3. システムの価値の所在が仕組みからプロンプトに移行 今回の記事を作成する際、実装時間の10倍程度は、プロンプトの検証と精度向上の時間に費やしたと思います。 今回の検証を通じて感じたのは、システムという仕組み自体にはさほどの価値はなく、プロンプトの精度を高めることが重要だと言うことです。 システム自体を、十分に柔軟な設計にしておいた上で、システムを仮説検証用の実験マシンと位置づけ、インプットとアウトプットの試行錯誤を繰り返すことで、そのプロンプトを高めていくことが重要です。 今回のテーマにおける柔軟性とは、論点定義、メンバー定義、ステップ定義などを自由に調整できる手段を提供するということを意味します。 以下に、実際にプロンプトを改善した具体例を2つ紹介します。 改善例1：技術的差別化戦略の論点を構造化 アプローチ2では、技術検証ステップのプロンプトで差別化戦略の指示が抽象的でした。 # 改善前（アプローチ2） 技術視点の差別化戦略：この事業アイディアを技術面でどのように差別化するかを記述してください この指示では、AIが「独自のAIモデルを構築する」のような一般的な記述に留まる傾向がありました。そこで、差別化戦略を4つの具体的な観点に分割しました。 # 改善後（アプローチ3） 技術視点の差別化戦略は、以下の観点について具体的に議論して作成してください。 * 採用する技術自体の差別化：他社が真似しづらい技術を採用することで差別化を図る戦略 * 顧客データ蓄積による差別化：顧客データが蓄積されることで、他社が真似しづらいサービスになるような戦略 * 競合サービスへのスイッチングコスト設計：スイッチングコストが高くなるようなサービス設計 * ネットワーク効果の設計：ネットワーク効果が働くようなサービス設計 この改善により、各事業アイディアに対して「データ蓄積によるレコメンド精度の向上」「ユーザーの履歴・設定データによるスイッチングコストの構築」など、観点ごとに具体的な差別化戦略が生成されるようになりました。 改善例2：事業の持続可能性に関する制約を追加 アプローチ2のブレインストーミングでは、市場やソリューションに関する基本的な制約のみを記述していました。しかし、生成された事業アイディアを確認すると、初期顧客の獲得方法や長期的な競争優位性が曖昧なまま議論が進んでいました。そこで、アプローチ3では以下の制約を追加しました。 # 改善後（アプローチ3で追加した制約） * 広告ゼロで最初の50人を獲得する具体的な経路を設計してください（以下の点を明示） * コミュニティ名、接触方法、提供する最初の価値、想定CVR * この事業を3年間続けると仮定した時、創業者が疲弊しない構造か検証してください * クレーム頻度、責任リスク、サポート負荷 * この事業が5年後に模倣された場合、価格競争に陥らない非価格競争優位性を定義してください * 独自データ、ネットワーク効果、コミュニティロックイン、スイッチングコスト この改善により、ブレインストーミングの段階から「ニッチコミュニティでの口コミ経由で初期50人を獲得」「データ蓄積によるスイッチングコスト構築」など、実行可能性の高い事業計画が生成されるようになりました。 4. 議論およびアウトプットの品質を上げるPDCA 最初から完璧なプロンプトを定義し、完璧なアウトプットを得ることは非常に困難でしょう。 最初のプロンプトは初期仮説に過ぎず、進化させるものという意識が大切だと思います。プロンプトから得たアウトプットというフィードバックに対して、人間側が持つ期待値との違和感から、これまで言語化出来ていなかった概念や制約を発見することができ、インプットとなるプロンプトを改善することが出来ます。 最初から"正解"となるステップ定義、トポロジー定義、プロンプトありきで、硬直的にシステムを構築するべきではないと思います。全ての要素を変更可能な要素として柔軟な設計にしておき、PDCAを回すことで精度を上げる工程が大切だと思います。 5. トップダウン的な議論分割とボトムアップ的な統合 マルチエージェントの仕組みをシステムに組み込む場合、トップダウン的な議論のステップ分割をし、各小規模の議論のチューニングをした上で、ボトムアップ的に各ステップを統合するアプローチが良いと思われます。 論点の粒度が荒すぎると十分な精度の成果が得られないでしょう。 大きな議論は小さな議論へと分割し、各論点がシャープになったところで、試行錯誤をした上でプロンプトとアウトプットの精度を高め、小さな議論を統合することで、結果として大きな議論のアウトプットの精度を高めることが出来ます。 6. エンドユーザーや顧客のニーズに合わせたDIY的システムというパラダイム 個人的には、マルチエージェントシステムは、そのエンドユーザーや顧客の状況やニーズに合わせたDIY的なシステムを構築するイメージに近い感覚があります。 これまでの大手システムベンダーが提供するパッケージやSaaSは、提供者が規定する仕様にユーザーが合わせるのが一般的でした。しかし、マルチエージェントをはじめ、AIを活用したシステムでは、プロンプトでエンドユーザーや顧客のコンテキストを詳細に入力することで、十分にカスタマイズされた仕様のシステムを構築することが出来ます。 今後の展望 様々な考察が得られた今回の検証ですが、以下のやり残したことや課題がいくつかあります。 1. ファシリテーターの導入 2. 議論トポロジーの多様化 3. エンドユーザー独自の制約定義 4. 議論の評価基準の設計 1. ファシリテーターの導入 今回定義した議論の登場人物とは別に以下の役割を担うファシリテーターを導入する方が議論の正確さや効率が向上すると思われました。 結論の生成 成果物の生成 関連性の高い人物への発言指定 議論や成果物の品質チェック 現在は、事前に定義した順番に各人物が発言するラウンドロビン型となっていましたが、これでは前後関係の関連性が低く、ラウンド数を無駄に消費する可能性が高いです。ファシリテーターが前後のコンテキストから、関連性の高い人物を指名することでより議論が前進することが期待できます。 2. 議論トポロジーの多様化 議論トポロジーとは、発言や情報の流れの構造を指し、上記の通り今回の議論トポロジーは単純なラウンドロビン型でした。 議論トポロジーとしては、以下のようなものが考えられ、議論に合ったトポロジーを選択することで議論や成果物の精度が向上することが期待されます。 トポロジー名 概要 出力傾向 ファシリテーター中心型（ハブ型） 各エージェントは直接議論せず、全てファシリテーターを経由する。 発散的・創造的 並列独立型（ブラインド並列） 各エージェントは同時に独立して回答し、最後に統合する。 多様性重視 クロスレビュー型（相互批判） エージェントAが仮説を出し、エージェントBが専門的視点から批評し、エージェントCが改善し、エージェントDが最終的に統合する、ような構造。 精度重視 ステップ分割をした際、各ステップ粒度で議論トポロジーを選択できるようにすれば、より議論の内容がシャープになるかもしれません。 3. エンドユーザー独自の制約定義 本当に実行する事業アイディアを考える場合、自分や組織固有の情報を事前にインプットする必要があると思います。 ここでは自分以外の人に見てもらうための記事ということで、プロンプトには一般的なことしか規定していません。そのため、誰にでも当てはまりそうな当たり障りない結論になっていると思います。 実際に自分事としてアイディア出しをする場合は、以下のような固有の情報を多くインプットする方がフィットするアイディアが出やすいでしょう。 大切にしているミッション 大切にする価値観 固有の詳細な事業選定ルール 固有のリソース制約条件 固有の投資戦略ルール 固有の事業撤退ルール ただし、価値観の認知バイアスを敢えて持たせない、という選択もあると思うので、その辺は目的に応じて使い分けるのが良いかと思います。 4. 議論の評価基準の設計 今回は、アウトプットの精度判定として、人間が見て納得感があるかと言った、感覚的かつ定性的なものに偏ってしまっていました。これは、アウトプットがアイディアのリストや、議論のプロセスが記載された議論レポートであったため、その精度を定量化するのが困難であったことが要因かと思われます。 このプロセス自体は、人間側が暗黙知を具現化するプロセスとして貴重だと思います。 ただ、定量的な評価が出来なければ、より明確な判断基準が定義することが出来ますし、アイディア出しから、高精度のアイディア絞り込み、を一気通貫で自動化することも可能になりそうです。 まとめ 今回は、新規事業構想という具体的なユースケースに基づき、マルチエージェントの活用法について検証しました。 もちろん、今回設定した議論トポロジーやステップ分割が最善とは言えないと思いますが、ステップ分割の仕方やプロンプト内容を変化させることで、大きくアウトプットの品質が変わることを確認することが出来ました。 検証プロセスの中で、議論を最小単位にすることで素早くフィードバックを得ることで、プロンプトの精度を向上させるPDCAのサイクルが重要であることを体感できたことは大きな収穫だと思います。 今回の議論は、新規事業選定という意思決定に限定されたものでしたが、このことはその他の議論にも当てはまることだと考えられます。 システムを提供する側としては、サービスの品質を向上するためにも、プロンプトとアウトプットのフィードバックシステムをエンドユーザーや顧客に提供することで、豊富なドメイン知識を持つ彼らにプロンプトの精度向上に積極的に参加してもらう、という設計を組み込む必要があるようにも感じます。 まだまだ奥が深いマルチエージェントの活用法ですが、本記事が具体的なイメージを持つきっかけになれば幸いです。

作業の合間に窓の外を眺めることはありますか？ 筆者の席は会社のビルの西側で、午後になると大きな窓から強烈な西日が射し込んできます。 それがあまりに強烈なので、いつもブラインドが閉まっていて外があまり見えません。 そのせいでオフィス内の移動中などに窓から見えた空が真っ暗で驚くということがよくあります。それで困るというわけではありませんが、少し味気ない感じがします。 空の色で時間の移ろいを感じたい。 隙間から覗くこともある というわけで、机に置いて空の色で時間帯を知らせてくれるデバイスを作ることにしました。それだけでもつまらないので、机の上にあったら嬉しいポモドーロタイマーの機能も付けてみ

G-gen の堂原です。当記事では、Google Workspace の 共有ドライブ において、ファイルやフォルダが 組織外へ共有されてしまうことを防ぐ 方法を紹介します。「アクセスレベルによる制限」、「共有ドライブレベルでの制限」そして「管理コンソールを用いた組織部門レベルでの制限」の3手法を解説します。 はじめに アクセスレベルによる制限 共有ドライブレベルでの制限 組織部門レベルでの制限 はじめに 共有ドライブ は Google ドライブの機能であり、チームでファイルを保存、検索、アクセスすることができます。ファイルごと、またはフォルダごとん、組織内部のメンバーはもちろん、組織外部のメンバーに対してもアクセス権限を付与することができます。 参考 : 共有ドライブとは 共有ドライブのファイルやフォルダは、簡単な手順で他人に共有することができます。それゆえに、意図しない情報漏洩を防ぐためには、外部のメンバーに対する共有設定を適切にコントロールする必要があります。 参考 : Googleドライブの「やってはいけない」。ファイルをインターネット公開しない設定 - G-gen Tech Blog 当記事では、共有ドライブの外部共有を制限する以下の3つの方法を紹介します。 アクセスレベルによる制限 共有ドライブレベルでの制限 管理コンソールを用いた組織部門レベルでの制限 これらの手法のうち、1つ目が最も手軽に設定でき、3つ目が最も詳細に設定できます。 アクセスレベルによる制限 共有ドライブ内のファイルやフォルダをユーザーやグループに共有するためには、操作を行うユーザーが、対象となるファイルやフォルダに対して適切な アクセスレベル （アクセス権限）を持っている必要があります。必要最低限のアクセスレベルを付与することで、不用意な外部共有を防ぐことができます。 ファイルとフォルダで、共有操作に必要なアクセスレベルは異なります。 ファイルを共有する場合 : 「管理者」、「コンテンツ管理者」、「投稿者」のいずれかが必要 フォルダを共有する場合 : 「管理者」、「コンテンツ管理者」のいずれかが必要 さらに、フォルダの共有に関しては、共有ドライブの設定で、コンテンツ管理者による共有操作を禁止することができます。 共有ドライブの画面において、ページ上部の共有ドライブ名をクリック ドロップダウンメニューが表示されるので、「共有ドライブの設定」をクリック 3.「コンテンツ管理者にフォルダの共有を許可する」のチェックを外す なお、上記の状態でコンテンツ管理者が共有操作をしようとすると、管理者に対して以下のようなリクエストメールが送信されます。 参考 : 共有ドライブのファイルへのアクセスの仕組み - Google Workspace ラーニング センター 共有ドライブレベルでの制限 共有ドライブの設定を変更することで、その共有ドライブにおける外部共有を一律で制御できます。 共有ドライブの画面において、ページ上部の共有ドライブ名をクリック ドロップダウンメニューが表示されるので、「共有ドライブの設定」をクリック 3.「（Google Workspace アカウント名）外のユーザーにファイルへのアクセスを許可する」のチェックを外す 組織部門レベルでの制限 共有ドライブは、Google Workspace のいずれかの 組織部門 に必ず所属します。デフォルトでは最上位の組織部門に属していますが、管理コンソールから任意の組織部門に移動させることができます。 3つ目の方法として、共有ドライブが所属する組織部門レベルの設定で、外部共有を制限することができます。 管理コンソール（ https://admin.google.com/ ）にログイン 左のサイドバーの「アプリ」をクリック 「Google Workspace」をクリック 「ドライブとドキュメント」をクリック 「ドライブとドキュメントの設定」に遷移するため、設定項目にある「共有設定」をクリック 6.共有ドライブが所属する組織部門を選択 7.「共有オプション」をクリック 8.「（Google Workspace アカウント名）の外部との共有」から、設定したい項目を選択 ここで選択できるオプションは以下のとおりです。 オフ : 外部との共有を一律で制限する 許可リスト登録済みドメイン : 管理コンソールで事前に設定した、許可されたドメインのユーザーにのみ共有を許可する オン : 外部との共有を制限しない この設定には継承の概念があり、親の組織部門で設定された内容は子の組織部門にも反映されます。この設定は、子の組織部門で上書きすることも可能です。 参考 : 組織の外部共有を管理する - Google Workspace 管理者 ヘルプ 堂原 竜希 (記事一覧) クラウドソリューション部クラウドエクスプローラ課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024, 2025に選出 (2024年はRookie of the year、2025年はFellowにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara