はじめに
「現場で活用するためのAIエージェント実践入門」の第10章で私がつまずいたことのメモです。
（このメモのほかの章へ：1章 / 2章 / 3章 / 4章 / 5章 / 6章 / 7章 / 8章 / 9章 / 10章 / まとめ）
第10章 各社のAIエージェントの実用化に向けた取り組み
この章は、著者陣が関わる3社（電通総研・Algomatic・ジェネラティブエージェンツ） における、AIエージェント実用化に向けた取り組みの紹介です。
10.1 プロジェクトの進め方（電通総研）
私は前職でAIチャットボットやRAGサービスのPoC、導入、オンボーディングなどを担当していたのですが、電通総研の進め方と同じような流れでした。
なお、AIエージェントにすべきかどうかの判断が重要というのはその通りだと思います。お客様の中には「AIエージェントを導入する！」が目的になってしまっている方もいるかと思いますので、AIエージェント化が適していない場合にどう説得するかが腕の見せ所かもしれません。5年ほど前のDXブームの時も、中期経営計画などにDXへ取り組むことを掲げる企業が多くなりましたが、その手段を導入することが目的になってしまっているように感じる話がよくありました。
そういえば先日、拡張RAGとエージェンティックRAGを比較する論文が発表されていました。どちらもRAGの発展形ですが、前者は固定のワークフローによる拡張で、後者はAIエージェントによる適応力や自立性に期待した拡張です。後者の方が良い結果になるかと思いきや、タスクによっては拡張RAGの方が優れていたものもありました。また、コストやレイテンシーも拡張RAGの方が優れています。なんでもAIエージェントにすればよいというわけではない一例といえるかもしれません。詳細はこちらです。
10.2 AIエージェントの開発（Algomatic）
Algomaticの不確実性の解消を最優先に考える話はその通りだと思います。MVP（Minimum Viable Product）の話ですね。
MVPという言葉が一人歩きしてMinimum（最小限）というのがネガティブに取られたりViable（実用可能）という言葉から完成品であるべきと思われてしまったりと混乱も多い言葉ですが、本来はフィードバックのサイクルを早く回し始めて無駄な開発を避けることが大切という話です。本の注釈でも紹介されていますが、スケートボードから車へ進化する図で有名になった記事はこちらです。
ドメインエキスパートが生成AIを活用できないとAIエージェントの導入には進めないという話も、その通りだと思います。3年前くらいまでは、ドメインエキスパートの方がAIを活用できるようになるのは至難の業だったかと思いますが、ChatGPTの登場以降、AI活用のハードルがすごく下がりましたし、エンジニアがAIを活用して業務を効率的に把握することもできるようになってきましたので、ドメインエキスパートとエンジニアの溝は埋まりやすくなってきたように思います。
10.3 AIエージェントと協働するためにはどうすれば良いのか（ジェネラティブエージェンツ）
私の所属会社の紹介です。本に出てくる西見さんの著書「その仕事、AIエージェントがやっておきました」はこちらです。
また、2025年12月のAI Builders Dayで弊社の最新の取り組み状況を弊社メンバーがお話していますので、ご興味ありましたらこちらをご参照ください。
10.4 まとめ
各社のAIエージェントプロジェクトの進め方が大変参考になりました。
（このメモのほかの章へ：1章 / 2章 / 3章 / 4章 / 5章 / 6章 / 7章 / 8章 / 9章 / 10章 / まとめ）