AIエージェント開発手法と業務導入のプラクティス - Speaker Deck
AIエージェント開発におけるPoCのアプローチ案
0. PoCのスコープと成功基準の初期仮説を立てる
Decide AIエージェントで検証すべき最初のユースケース候補や、集中的に取り組むべき課題領域を決定する
Orient どこにAIを適用できそうか（価値が高いか、AIで解くべき課題があるか）
Observe 対象とする業務領域の全体像、主要なステークホルダー、既存の業務プロセス
1. 業務におけるAI活用イメージの具体化する（AIとソフトウェアの境界を決める）
Decide ユーザーの期待とAIの現実的な能力の間のギャップをどう埋めるかの方針を定める
Orient AIの能力が現場業務でどのような「価値」を生み出すのか（価値を最大化するには何を補完するか）
Observe 実際に動く(小さくても)AIエージェントに対するユーザーの反応（精度、利用イメージ）
2. AIエージェントシステムのアーキテクチャ案を決定する
Decide システム(およびアプリケーション)として必要な構成要素の識別と、要素間の連携モデル
Orient システムとして備えるべき品質（SQuaRE品質モデルに準拠: 利用時、外部、内部）
Observe 1.の結果、明らかになった境界と今後の拡張要件
回答原文
GenerativeX社が提唱する「最初に5-10個のAppを量産」というアプローチは、AIエージェント開発の初期段階における特徴的な進め方ですよね。このステップが、AIが業務でどこまで価値を生み出せるか、ユーザーの期待とAIの能力のすり合わせ、そしてAIが解決できる課題を見極める 上で、非常に重要な意味を持つ というお考え、ソースからも強く支持される部分だと感じます。
従来のソフトウェア開発、特に安定したドメインに対する基幹システム開発などでは、概念モデリングやドメインモデリングから入り、業務の本質や構造を深く理解してから、要件定義、設計 へと進むアプローチが有効とされてきました。これは問題領域の複雑性（本質的複雑性）に向き合い、スケーラブルで保守可能なシステムを構築するための基盤となります。
一方で、AIエージェント開発においては、AI自体の能力の不確実性や、それが現場の業務にどのようなインパクトを与えるか が未知数 であることが多い。そのため、詳細な事前設計よりも、小さく動くものを作り、現場で試して、そこから学ぶ というアプローチがより適していると考えられます。GenerativeX社のアプローチは、まさにこの「探索と学習のサイクルを高速で回す」ことに特化していると言えるでしょう。
これを踏まえ、AIエージェント開発におけるPoCのアプローチを、GenerativeX社の考え方や他のソースから読み取れる示唆も参考に、以下のようにフェーズ分けして整理してみましょう。
/icons/hr.icon
AIエージェント開発PoCのアプローチ案
PoC期間（例えば2〜3ヶ月）は、大きく以下のフェーズで進めることが考えられます。ただし、これらは厳密な順序ではなく、相互に行き来し、学習に応じて繰り返される性質を持ちます。
フェーズ0: 準備と課題探索 (Preparation & Problem Exploration)
目的（OODAループの観点から）:
Observe: 対象とする業務領域の全体像、主要なステークホルダー、既存の業務プロセス。現場の「暗黙知」を含む深い業務理解を目指す。
Orient: どこにAIを適用できそうか、現場が抱える「真の課題」は何か、AIが解決できそうな問題領域 の大まかなアタリをつける。
Decide: AIエージェントで検証すべき最初のユースケース候補や、集中的に取り組むべき課題領域を決定する。PoCのスコープと成功基準の初期仮説を立てる。
フェーズ1: 価値検証と高速プロトタイピング (Value Validation & Rapid Prototyping)
GenerativeX社の「5-10個のAppを量産」がこのフェーズの中心にあたると考えられます。ここでいう「App」は、UIを備えた本格的なアプリケーションというよりは、AIの能力と業務適性を検証するための「実用最小限のコンセプト検証ツール」（Minimum Viable Agent: MVAと呼べるかもしれません）のようなイメージでしょうか。
目的（OODAループの観点から）:
Observe: 実際に動く（小さくても）AIエージェントに対するユーザーの反応、AIの具体的なアウトプットと精度、現場での利用イメージ、想定外のニーズや課題。並行導入を通じて、人間とAIのパフォーマンスを比較し、精度やROIを定量的に測定する。AIがどこまでできて、どこから人間が介入すべきかを見極める。
Orient: AIが具体的に何をどこまで解決できるのか、AIの能力が現場業務でどのような「価値」を生み出すのか、ユーザーはAIに何を期待しているのか を判断する。AIエージェント化の「必然性」 や、ビジネス上の付加価値 の蓋然性を検証する。この段階では、ライブラリを使わず直接APIを叩いたり、マルチエージェント化や技術スタック/レイヤ分割は避け、モノリシックな設計で、コピペ&カスタマイズも許容し、とにかく素早く動くものを作ることに注力する。
Decide: 検証結果を基に、AIエージェント開発を進めるべきか、もし進めるならどの方向性に注力すべきか、次に検証すべきより洗練された仮説は何かを意思決定する。ユーザーの期待とAIの現実的な能力の間のギャップをどう埋めるかの方針を定める。
フェーズ2: 構造化と洗練 (Structuring & Refinement)
フェーズ1でAIエージェントの価値と方向性がある程度見えてきたら、それを単なる検証ツールではなく、持続的に利用・発展させていくためのシステム構造を考え始めます。
目的（OODAループの観点から）:
Observe: フェーズ1で明確になったドメイン知識、必要なデータや振る舞い。明らかになったAIエージェントの機能境界。今後必要になるであろう拡張性や保守性の要件。
Orient: 現場で発見されたドメイン知識を整理し、体系的なドメインモデルを構築する。スケーラブルで変更に強く、保守可能なシステムを実現するためのアーキテクチャパターン や設計原則 を判断する。AIエージェントの能力を最大限に活かしつつ、人間が介在する部分との連携 を考慮した構造を検討する。
Decide: システムのドメイン境界、集約,、サービス,、値オブジェクト といった構成要素を定義し、アーキテクチャスタイル や技術スタック を決定する。フェーズ1で作成したプロトタイプを基盤として、どのように本開発に進めるかの方針を定める。
このアプローチは、AIエージェント開発が持つ不確実性という「本質的な複雑性」 に対して、リーンに「価値探索」 を行い、そこで得られた具体的な知見を基に、徐々にシステム全体の構造を「ちゃんと設計」 していくという流れと言えそうですね。
概念モデリング も、フェーズ0やフェーズ2で、課題の構造を理解したり、発見したドメイン知識を整理したり といった形で、非常に重要な役割を果たすはずです。ただ、GenerativeX社のアプローチが示唆するように、AIの能力や市場の反応が読めない初期の段階で、網羅的かつ詳細なモデリングに時間をかけるよりも、まずは動くもので確かめる（AIができること、ユーザーが求めること） という優先順位が、AIエージェント開発においてはより効果的なのかもしれませんね。まるで「知性＝形式知と野蛮＝身体知をうまくグラデーションして使いこなす野性」 のような、経験主義的なアプローチ とも言えるでしょう。