はじめに こんにちは。グローバルシステム部 バックエンドブロックの髙橋と松浦です。私たちはZOZOMETRY・ZOZOMAT・ZOZOGLASSなどのシステムを開発、運用しています。 今回、エンジニアリング全般の知見を深めるため、2026年2月21日にオーストラリア・メルボルンで開催された DDD Melbourne に参加しました。この記事ではDDD Melbourneに現地参加した経験や、セッションを通じて学んだ内容を紹介します。 はじめに DDD Melbourneとは 現地の様子 気になったセッション紹介 How To Write Awful Unmaintainable Code 副作用 技術的負債 まとめ The Safety First App: 12 product patterns that turn failures into recoveries Autosave + draft states Explainable errors まとめ Managing for Failure 心に残ったポイント まとめ Throw Away The Vibes: Context Engineering Is All You Need コンテキストの4つの失敗モード Breadcrumb Protocol Research → Plan → Implement → Review（RPIR）フロー コンテキストサイズの60％ルール まとめ 最後に DDD Melbourneとは DDD Melbourneは、非営利団体Oz Dev Inc.が主催するソフトウェアコミュニティのカンファレンスです。 このカンファレンスでの「DDD」とは「Developer! Developer! Developer!」の略で、英国・オーストラリア・ヨーロッパ各地で開催されており、ソフトウェアに関わるさまざまな業種の方が、開発についてのプラクティスを共有しています。 セッションのテーマは毎年コミュニティの投票によって決定されるため、今年のトレンドや関心事が反映されているのも、このカンファレンスのポイントです。登壇者にはエンジニア、デザイナー、プロダクトマネージャーなど多様なバックグラウンドを持つ方々がいます。そのため、実践的な知見や生々しい失敗談など、現場のリアルな声を聞けることが特徴です。今回発表された内容も、AIについての問題点や開発手法から、エンジニアとしてのマインドセットまでかなり幅広く、発表者の興味や経験が伝わってくる内容でした。 現地の様子 本カンファレンスは150年以上の歴史を持つMelbourne Town Hallで行われました。 Melbourne Town Hall オープニング前の様子 オープニングの様子 気になったセッション紹介 How To Write Awful Unmaintainable Code このセッションでは、ベストプラクティスとアンチパターンを対比して、何が悪いかをコントのように共有していたのが印象的でした。 前半では、命名・バージョニング・コミットといった基本的なテーマから始まり、コミットを小さく保つことやセマンティックバージョニングを正しく使うことの重要性が語られていました。対比として、政治的・組織的にバージョンが決められるEnigmatic Versioningの話がスライドに出され、会場も笑いに包まれました。 Enigmatic Versioning 後半は、副作用と技術的負債が主な話題でした。 副作用 良いコードとは「関数が1つのことだけを行い、関数名が正確にそのことだけを説明している」という定義の話から入り、無害に見える関数が副作用を持っていたという例が挙げられていました。 意図した副作用は時に必要ですが、基本的には避けるのがベターだと考えますし、名前や仕組みで判断できないのはバグの原因になりかねないので、改めて注意が必要だと認識しました。 技術的負債 米国の金融企業Knight Capitalは2012年、高値で買い、安値で売るロジックを含むデッドコードが本番環境で動作してしまいました。約45分間で約4億4,000万ドルの損失を出し、最終的にGetco社との合併に至りました。近しい金額のNASAの火星探査機喪失と比較されるほど、デッドコードの危険性を示す象徴的な事例として紹介されていました。 まとめ あるあるネタから始まりつつ、後半になるにつれて話の重みがどんどん増していきました。Knight Capitalの事例は特に衝撃的で、コードの管理不足が会社の経営危機にまで繋がってしまった話はとても印象的な事例でした。技術的負債や構造の問題は、放置すれば取り返しのつかない事態になり得るため、改めてコード管理には気をつけたいと再認識したセッションでした。 The Safety First App: 12 product patterns that turn failures into recoveries このセッションは、「ほとんどのアプリケーションは晴れの日のために作られている」という一言から始まりました。しかし、ユーザーは必ずミスをしますし、ネットワークは揺らぎます。APIはタイムアウトします。そして人は焦ると間違ったボタンを押します。それでもなお、多くのプロダクトは正常系という「晴れの日」だけを前提に設計されています。 このセッションでは、異常系「雨の日」を前提にした設計をどうプロダクトに組み込むかを、12のパターンに分解して紹介していました。単なるUX改善の話にとどまらず、プロダクトマネージャー・デザイナー・エンジニアが共通言語を持つための内容でした。 The Safety First App: 12 product patterns that turn failures into recoveries 以下が本セッションで紹介された12パターンです。 Pattern 1: Undo Everywhere（どこでもUndo） Pattern 2: Auto-save & Draft States（自動保存とドラフト状態） Pattern 3: Guard Destructive Actions（破壊的アクションの防御） Pattern 4: Resilient Forms（回復力のあるフォーム） Pattern 5: Explainable Errors（説明可能なエラー） Pattern 6: Quick Recovery Links（クイックリカバリーリンク） Pattern 7: Degraded States（劣化状態） Pattern 8: Idempotent Actions（べき等アクション） Pattern 9: Long-running Work with Receipts（レシート付き長時間処理） Pattern 10: Outbox & Offline Queue（アウトボックスとオフラインキュー） Pattern 11: Rescue Mode（レスキューモード） Pattern 12: Customer-facing Runbooks（カスタマー向けランブック） この中でも、印象深かったものは以下の2つです。 Autosave + draft states このセッションで重要視されていたのは、意味のある変更ごとにドラフト状態を永続化することでした。保存処理をアプリケーションのインフラとして扱ってほしいということです。例えば長いフォームがあった時、タイムアウトしてデータが消失したら、大きなストレスになります。「また入力し直しだ」と感じた経験は多くの方にあるはずです。自動的にドラフトが保存されていれば、そういったことはなくなり、ユーザーは安心して入力を行えます。 また、現在の状態をユーザーに通知することも重要です。インジケーターがあると、ユーザーは正しく保存されていることを確認できるため、安心につながります。 身近な例だと、ドキュメント編集ツールの「保存しました」「保存中...」といったインジケーターが挙げられます。編集中に保存状態が常に表示されていることで、ユーザーはデータが失われていないことを確認でき、安心して作業を続けられます。 Explainable errors エンジニアならお馴染みのHTTPステータスコードでは、404エラーや500エラーがあると思います。しかしそれらのエラーだけだと、ユーザー目線では何が起きたのかほぼわかりません。ユーザーには可能な限りわかりやすい、システム的な言語ではなくユーザーの言語で返してあげる必要があります。 例えばカード支払いだと 「支払いが失敗しました、別のカードをお試しください」 「△⚪︎の追加に失敗しました。再度試すか、別の方法を使ってください」 などです。これが、 「支払いに失敗しました」 「サーバーでエラーが発生しました」 だけだと、ユーザーは何が間違いかが分からないので、解決しようがありません。 何が発生しており、次にユーザーが何をすべきかを示すことが重要です。リトライすべきか、編集し直すべきか、サポートに連絡すべきか。明確なエラーメッセージを返していると、ユーザーが主体的に問題を解決する糸口になります。サポートやインシデントトリアージを行いやすくするために、問い合わせ用のIDをレスポンスに含めることも大切です。 まとめ Autosave + draft statesは、データを扱うと必ず発生する保存と復元の話ですが、ただ保存と読み込みをするだけでは、ユーザーにとって大変になるケースもあることを再認識させられました。ユーザーが意識しなくても困らない仕組みや、いざという時にいつでも状況を確認できる状態を作っておくと、ユーザー自身で解決できることも増えます。また、仮に問題が起こったとしてもより細かく対応ができると思うので、UIを考える上で今後の開発で意識していきます。 Explainable errorsでは、プロダクト開発の現場で見落とされがちなユーザー向けのエラー通知の改善が紹介されていました。エラーの内容と具体的な対処法が適切に提示されていれば、ユーザー自身で解決できるケースは決して少なくありません。今後の開発では、ユーザーができるだけ自力で問題を解消できるようにするには、どのような情報をどの粒度で見せるべきか、という観点でインタフェースを設計していきたいと感じました。 本セッションでは触れられていませんでしたが、参考例としてMetaのGraph APIがあります。このAPIでは、開発者向けの詳細なエラー情報に加えて、ユーザー向けタイトルとメッセージを返却するフィールドも用意されています。 { " error ": { " message ": " Message describing the error ", " type ": " OAuthException ", " code ": 190 , " error_subcode ": 460 , " error_user_title ": " A title ", " error_user_msg ": " A message ", " fbtrace_id ": " EJplcsCHuLu " } } https://developers.facebook.com/docs/graph-api/guides/error-handling?locale=ja_JP もちろんこれらを行うには、相応の管理コストがかかります。そのため、どこまでを丁寧に設計・運用するかという境界を意識することが重要です。現実的には、ユーザー体験への影響が大きい部分には優先的にコストをかけ、それ以外の内部的な部分は、開発・運用の生産性とのバランスを取りながら設計していく姿勢が大事だと考えています。 今回紹介された12パターンの多くは、障害やユーザーの「ミスが起きてから」ではなく「ミスが起きないようにする」設計の話です。安全機構は後付けではなく、最初から盛り込むべきものであることを、改めて実感しました。 Managing for Failure このセッションは「なぜ失敗が必要なのか？　それは、失敗を減らすためだ」という問いかけから始まりました。「失敗がないチームは一見健全に見えるが、学習も、成長も止まっている可能性がある。そこで、失敗を安全に経験させる仕組みをどう設計するか」という話が展開されていきました。 このセッションでは、「失敗を減らすために、あえて失敗を設計する」という話が、精神論ではなくかなり具体的なやり方まで踏み込んで展開されていました。 Managing for Failure 心に残ったポイント 30/15 Fail 30分詰まったら15分離れ、戻っても進まなければ「失敗達成」でヘルプを出す方法が紹介されました。失敗をゴールにすることで、行き詰まったこと自体が「達成」になります。助けを求めるハードルが下がる仕組みです。「失敗をゴールにする」という発想が面白かったです。 Fire Drill 実際の障害が起きる前に、意図的に壊して復旧練習をします。本番で強くなるには、練習で失敗しておくことが重要です。これはインフラでもアプリでも同じだと感じました。 私たちのチームでもカオスエンジニアリングの考え方を取り入れて います。 まとめ 印象的だったのは、「失敗は避けるものではなく、慣れるもの。そして、ちゃんと扱えるようにするもの」という考え方です。「うまくいきすぎているチームは、一見健全に見えるが、挑戦していないだけかもしれない」という指摘も印象的でした。 失敗を減らすために、まずは安全に失敗できる場をつくる。何事も慣れや練度が大切だと実感しました。 Throw Away The Vibes: Context Engineering Is All You Need このセッションでは、主にVibe codingについての出力問題とその解決策を模索する話がされていました。生成されたコードは一見、問題なさそうに見えるのですが、実際にそのコードをプロジェクトで使おうとすると、さまざまな問題を抱えておりそのまま使うことはできないコードになることが多いです。たとえプロンプトをうまく書いても、間違ったコードが出てくることがあります。それは、前提のコンテキストが誤っているから、という話でした。 コンテキストの4つの失敗モード LLMのコンテキストには「Poisoning（汚染）」「Distraction（注意散漫）」「Confusion（混乱）」「Clash（衝突）」という4つの失敗パターンがあります。 コンテキストの4つの失敗モード Poisoning（汚染） これは巷でよく言われている、ハルシネーションがコンテキスト内に含まれている状態を指します。ハルシネーションによる誤った情報がコンテキスト内に残ると、そのスレッドではずっと間違った情報をもとに回答を出力してしまいます。 Distraction（注意散漫） 大きいコンテキストの中に複数の要素が保存されている場合、AIが見る場所を間違えると誤った情報に注目してしまい、出力結果が悪くなってしまいます。 Confusion（混乱） 不必要な情報が存在していると、AIは判断ができなくなります。複数の無関係な情報を1つの文脈と誤認し、出力が不安定になるためです。 Clash（衝突） 矛盾した情報が存在していても、Confusionと同様にAIは判断ができなくなります。 これらを解決するには、単純ですが「適切なタイミングで適切なコンテキストを提供すること」という原則を守ることが大切ということでした。以降は、適切にコンテキストを共有するには、どのようなテクニックがあるかが解説されました。 Breadcrumb Protocol スクラッチパッドとしてMarkdownファイルを作り、エージェントと人間がそこに計画やタスクの進捗を書き込んでいく手法です。セッションが壊れても、このファイルさえあれば新しいセッションで続きから再開できる。間違った判断があれば、ファイルを更新するだけで次回からエージェントが正しい振る舞いをするようになる。 「コンテキストを外部に永続化して、セッションに依存しない」という発想が面白かったです。私たちのチームでも同様のアプローチでエージェントへの指示を管理しているので、共感する部分が多かったです。 Research → Plan → Implement → Review（RPIR）フロー いきなりコードを書かせるのではなく、まずリサーチさせて計画を立て、タスク分割してから実装し、最後にレビューするという流れです。LLMは「やれと言われたこと」は何でもやろうとする。逆に言えば「やるなと言わないとやってしまう」。だからこそ、やることを制約する（constrain）のが安定した出力を得る鍵になる。PRレビューで大量の差分を見るのではなく、RPIRの各ステップで段階的にレビューするという考え方は、実務にすぐ取り入れられそうです。 コンテキストサイズの60％ルール コーディングエージェントのコンテキストサイズが60％を超えたら、圧縮（compaction）するか新しいスレッドを始めるべきだという実践的なアドバイスがありました。100万トークン入るからといって全部使えるわけではなく、一定量を超えるとモデルの出力品質が落ちるという話は、普段の開発でも意識しておきたいポイントです。 まとめ AIコーディングの成果は「モデルの性能」ではなく「コンテキストの質」で決まるという話でした。そして、コンテキストの質は「AI」ではなく、「人間」が設計するものです。AIの性能は日々向上していますが、最終的なコア部分は人間の管理がものを言うという結論が印象的でした。 ツールをあれこれ試すよりも、1つのツールに腰を据えて、コンテキストの渡し方を磨くことが重要です。人間の専門性、足場づくり（scaffolding）、方向づけ（steering）は今後もAIコーディングを行う上で不可欠な技術になっていくと思われます。 最近のAIコーディングエージェントでは、まさにこれらの内容をアシストするための仕組みが、システムの仕様として組み込まれている印象があります。AIが進化していくと、品質部分はますますコンテキストの質が担うことになりそうです。コンテキストの整理はAIだけではなく、自身の頭を整理するという意味でも、もちろん有用なので、うまく整理できる能力を磨いていきたいと思います。 最後に 今回DDD Melbourneに参加し、世界のエンジニアが持つ課題意識と、その対応策を学びました。特に、AI周りはZOZOでも幅広く活用しているため、コンテキストについての話は参考になりました。また、海外カンファレンスへの現地参加を通じて、日本とのカンファレンス文化の違いも体感でき、貴重な経験になりました。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

Amazon S3 の一般提供が開始されたのは、20 年前の先週にあたる 2006 年 3 月 14 日でした。 Amazon Simple Storage Service は、クラウドインフラストラクチャを定義した基礎的なストレージサービスだと考えられがちですが、シンプルなオブジェクトストレージサービスとして始まった S3 は、今でははるかに広い範囲と規模を備えたサービスへと成長を遂げました。 2026 年 3 月現在、S3 には 500 兆を超えるオブジェクトが格納されており、何百エクサバイトものデータ全体で 1 秒あたり 2 億件を超えるリクエストをグローバルに処理しています。料金は 1 ギガバイトあたり 2 セントを少し超える程度まで下がっており、リリース時から約 85% 削減されたことになります。私の同僚である Sébastien Stormacq が、「 Amazon S3 の 20 年を振り返り、未来を築く 」でエンジニアリングと今後の展望に関する詳しい記事を書きました。AWS の最初のお客様と、これらのお客様が現在の AWS をどのように形作ったかに関心がある場合は、「 How three startups helped Amazon invent cloud computing and paved the way for AI 」をぜひお読みください。20 年。これは立ち止まって祝うに値する年月です。 S3 の 20 周年記念に伴い、今週は Channy Yun も S3 の新機能、Amazon S3 汎用バケットのアカウントリージョナル名前空間に関する記事を書きました。この機能を使用すると、リクエストするバケット名にアカウント固有のサフィックスを追加することで、ユーザー独自のアカウントリージョナル名前空間内に汎用バケットを作成できるため、使用したい名前がユーザーのアカウント専用に常時予約されるようになります。新しい s3:x-amz-bucket-namespace 条件キーを用いた AWS IAM ポリシーと AWS Organizations サービスコントロールポリシーを使用して、組織全体での導入を強制できます。 Amazon S3 汎用バケットのアカウントリージョナル名前空間の詳細については、 Channy の記事 をお読みください。 2026 年 3 月 16 日週に行われた注目のリリースは、 Amazon Route 53 Global Resolver の一般提供 です。このサービスは、私自身との個人的なつながりがあるものです。昨年の re:Invent 2025 でのこの機能の プレビュー に関する記事を書いたのですが、とても楽しく取り組めた記事だったので、一般提供が開始されたと聞いて本当に嬉しく思っています。 インターネット経由でアクセスできるエニーキャスト DNS リゾルバーである Amazon Route 53 Global Resolver は、どこからでも承認済みクライアントに DNS 解決を提供できます。30 の AWS リージョンで一般提供が開始されており、IPv4 と IPv6 両方の DNS クエリトラフィックをサポートします。Route 53 Global Resolver は、組織内の認証済みクライアントに対し、Route 53 プライベートホストゾーンに関連付けられたパブリックインターネットドメインとプライベートドメインのエニーキャスト DNS 解決を、特定の VPC やリージョン内だけでなく、どこからでも提供します。また、悪意があると考えられるドメイン、職場に不適切なドメイン、および DNS トンネリングやドメイン生成アルゴリズム (DGA) などの高度な DNS 脅威に関連するドメインをブロックするための DNS クエリフィルタリング機能も提供されており、一元化されたクエリのログ記録機能も含まれています。一般提供された Global Resolver は、辞書ベースの DGA 脅威に対する保護を強化します。 2026 年 3 月 9 日週のリリース 以下は、2026 年 3 月 9 日週に行われたその他の発表の一部です。 Amazon Bedrock AgentCore Runtime がステートフル MCP サーバー機能のサポートを開始 – Amazon Bedrock AgentCore Runtime が、ステートフルモデルコンテキストプロトコル (MCP) サーバー機能のサポートを開始しました。開発者はこの機能を使用して、リソース、プロンプト、およびツールに対する既存のサポートとともに、エリシテーション (情報の引き出し)、サンプリング、および進捗通知を使用する MCP サーバーを構築できます。ステートフル MCP セッションでは、分離されたリソースを用いる専用の MicroVM で各ユーザーセッションが実行され、サーバーは Mcp-Session-Id ヘッダーを使用して複数のやり取りにおけるセッションコンテキストを維持します。エリシテーションは、サーバーが開始するマルチターンの会話を行って、ツールの実行中に構造化された入力をユーザーから収集できるようにします。サンプリングは、パーソナライズされた推奨事項などのタスクのために、サーバーがクライアントに LLM 生成コンテンツをリクエストすることを可能にします。進捗通知は、長時間に及ぶ操作中でも、クライアントが情報を常に把握しておけるようにします。詳細については、 Amazon Bedrock AgentCore ドキュメントを参照してください。 Amazon WorkSpaces が Microsoft Windows Server 2025 のサポートを開始 – Amazon WorkSpaces Personal と Amazon WorkSpaces Core で Microsoft Windows Server 2025 を活用する新しいバンドルを利用できるようになりました。これらのバンドルには、Trusted Platform Module 2.0 (TPM 2.0)、Unified Extensible Firmware Interface (UEFI) Secure Boot、セキュアコアサーバー、Credential Guard、Hypervisor-protected Code Integrity (HVCI)、DNS-over-HTTPS などのセキュリティ機能が含まれています。既存の Windows Server 2016、2019、および 2022 のバンドルも引き続きご利用いただけます。マネージド Windows Server 2025 バンドルを使用することも、カスタムのバンドルとイメージを作成することも可能です。このサポートは、Amazon WorkSpaces が提供されているすべての AWS リージョンでご利用いただけます。詳細については、「 Amazon WorkSpaces のよくある質問 」をご覧ください。 AWS ビルダー ID が GitHub と Amazon を用いたサインインのサポートを開始 – AWS ビルダー ID でサポートされるソーシャルログインオプションに、GitHub と Amazon の 2 つのオプションが追加されました。これらのオプションは、既存の Google と Apple のサインイン機能に新たに追加されるものです。この更新により、開発者は一連の認証情報を個別に管理しなくても、既存の GitHub または Amazon のアカウント認証情報を使用して AWS ビルダー ID プロファイル (および AWS Builder Center、AWS トレーニングと認定、Kiro などのサービス) にアクセスできるようになります。詳細を確認して使用を開始するには、 AWS ビルダー ID ドキュメントをご覧ください。 Amazon Redshift に COPY 操作用の再利用可能なテンプレートを導入 – 頻繁に使用される COPY パラメータを保存して再利用できる COPY コマンド用のテンプレートが Amazon Redshift でサポートされるようになりました。テンプレートは、データインジェスト操作全体で一貫性を維持するために役立ち、COPY コマンドの実行に必要な労力を軽減して、将来の使用のすべてにテンプレート更新を自動適用することでメンテナンスを簡素化します。COPY テンプレートのサポートは、Amazon Redshift が提供されているすべての AWS リージョン (AWS GovCloud (米国) リージョンを含む) でご利用いただけます。使用を開始するには、こちらの ドキュメント を参照するか、ブログ記事「 Standardize Amazon Redshift operations using Templates 」をお読みください。 AWS のお知らせに関する詳しいリストについては、 ニュースブログ チャネルである「 AWS の最新情報 」ページをご覧ください。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – 2026 年の AWS Summit に参加しましょう。AWS Summit は、クラウドおよび AI 関連の新興テクノロジーを探求し、ベストプラクティスについて学び、業界の同業者や専門家とつながることができる無料の対面イベントです。次回の Summit は、 パリ (4 月 1 日)、 ロンドン (4 月 22 日)、 バンガロール (4 月 23〜24 日) で開催される予定です。 AWS Community Day – コミュニティリーダーたちがコンテンツを計画、調達、提供し、テクニカルディスカッション、ワークショップ、ハンズオンラボが行われるコミュニティ主導のカンファレンスです。今後のイベントには、 プネー (3 月 21 日)、 サンフランシスコ (4 月 10 日)、 ルーマニア (4 月 23～24 日) などがあります。 AWS at NVIDIA GTC 2026 – 2026 年 3 月 16～19 日に米国サンノゼで開催される NVIDIA GTC 2026 で、AWS のセッション、ブース、デモ、付帯イベントに参加しましょう。AWS 経由でイベントパスの 20% 割引を受け、GTC での 1 対 1 ミーティングをリクエストできます。 AWS Community GameDay Europe – 2026 年 3 月 17 日に行われる AWS Community GameDay Europe は、ヨーロッパの 50 を超える都市で同時開催される、チームベースのハンズオン AWS チャレンジイベントです。参加チームは、壊れた AWS 環境内 (誤設定されたサービス、欠陥のあるアーキテクチャ、セキュリティギャップ) に配置され、2 時間の制限時間内で環境を可能な限り修正する必要があります。最寄りの開催都市を見つけて、 awsgameday.eu でサインアップしてください。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。こちらのリンクから、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベント と デベロッパー向けのイベント をご覧いただけます。 2026 年 3 月 16 日週のニュースは以上です。2026 年 3 月 23 日週の Weekly Roundup もお楽しみに! – Esra この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。

はじめに こんにちは、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のサイクルが重要であることを体感できたことは大きな収穫だと思います。 今回の議論は、新規事業選定という意思決定に限定されたものでしたが、このことはその他の議論にも当てはまることだと考えられます。 システムを提供する側としては、サービスの品質を向上するためにも、プロンプトとアウトプットのフィードバックシステムをエンドユーザーや顧客に提供することで、豊富なドメイン知識を持つ彼らにプロンプトの精度向上に積極的に参加してもらう、という設計を組み込む必要があるようにも感じます。 まだまだ奥が深いマルチエージェントの活用法ですが、本記事が具体的なイメージを持つきっかけになれば幸いです。