「2026年はAIエージェント構築元年」——みのるん氏が示した、自前開発の現実解
AIエージェントを「使う」時代から「作る」時代へ。これはしばらく前から言われ続けているが、KDDIアジャイル開発センター（KAG）の御田稔氏（通称「みのるん」）の話を聞くと、その遷移が実際に起きつつあることがわかる。
2026年7月に行われた講演で御田氏が語ったのは、自前のAIエージェントを開発するための技術論ではなく、「なぜ作るか」「どこで詰まるか」「どう乗り越えるか」という実務の全体図だった。
「既製品で十分」ではない場面がある
まず前提の整理から始めよう。
オフィススイートに標準搭載されたAIチャットbot、Kiroのようなコーディング支援エージェントなど、汎用的に使えるAIエージェントはすでに多い。一般的な業務であれば、こうした既製ソリューションで十分なケースも多い、と御田氏は認める。
ただし、以下のような場面では話が変わる。自社固有のシステムとの連携が必要なとき。SaaSでは扱えない業務データを活用したいとき。独自のUIや体験を提供したいとき。あるいは、既製のエージェントを試してみたら「広告で示されるほど実用性が高くなかった」「自社の業務データにアクセスできない」という実態にぶつかったとき。
御田氏の言葉を借りると、「自社の業務やサービスに深く組み込むのであれば、自前で構築するメリットは大きい」。
これは技術者の特権的な主張ではない。業務のどこに摩擦があるかを知っている現場担当者が、既製品との差分を冷静に見極めたときに出てくる判断だ。
Strands AgentsとAgentCoreで何が変わったか
自前開発を選んだとして、その技術的ハードルはどう変わったのか。
AWSが提供するオープンソースフレームワーク「Strands Agents」は、PythonとTypeScriptに対応し、数行のコードでAmazon BedrockのClaudeを使ったエージェントを動かせる。御田氏は「これを見れば、Kiroを活用してAIエージェントを内製開発できそうだと感じるはずです」と語る。エージェントメモリ機能との組み合わせで会話履歴の保持も追加できるし、オープンソースゆえに自社要件に合わせた拡張や不具合修正も可能だ。
ただし、AIエージェントには従来のWebアプリケーションとは異なる設計要件がある。ストリーミングレスポンスへの対応、外部ツール利用時の認証・認可、会話履歴の管理、サーバレス運用によるコスト制御——これらを従来のやり方で実装しようとすると、「AWS Lambda、Amazon API Gateway、Amazon Cognitoなどを組み合わせて開発する必要があり、AWSに関する幅広い知識が必要」だと御田氏は言う。
この課題に応える形で2025年に登場したのが「AWS Bedrock AgentCore」だ。ランタイム、メモリ、アイデンティティ管理、オブザーバビリティといったAIエージェント特有の要件を、モジュールとしてSDK経由で組み込める。さらに「コードを書くこと自体が難しい」という層向けに、GUIベースでRAGやWeb検索・ブラウザ操作機能を追加できる「AgentCore Harness」も提供されている。従来はLambdaのコード実装が必要だった部分を、フルローコードで開発できるようになった。
フレームワーク、クラウド基盤、ローコードツールが三点セットで揃ってきた、というのが現状だ。「ハードルが下がった」という表現はよく使われるが、御田氏のケースでは具体的に「何のハードルが、どのサービスによって下がったか」が整理されているのが参考になる。
re:Inventエージェントという実践例
御田氏が具体的な実装例として紹介したのが「re:Inventエージェント」だ。AWS re:Invent 2025に参加する日本人向けに開発・公開されたAIエージェントで、渡航準備や持ち物確認、セッション検索、イベント期間中の新機能解説まで対応している。
システム構成はシンプルだ。フロントエンドにAWS Amplify（ReactとVite）、バックエンドにAgentCore RuntimeでStrands Agentsを稼働させる構成。Amazon Cognitoで最低限の認証を組み込み、サーバレス環境でPoCコストを抑えた。
設計上の判断として興味深いのは、マルチエージェントではなくシングルエージェント構成を選んだ点だ。複数エージェントを組み合わせると柔軟性は上がるが、設計と制御が複雑になる。御田氏はあえて「必要なツールを1つのエージェントに集約し、構成をシンプルに」した。「エージェントに次々と機能を追加していくと、実装は急速に複雑化し、将来的な拡張が難しくなる場合があります」という言葉は、実装経験から出た判断だ。
RAGの実装にも工夫がある。事前にAIチャットbotで情報を収集し、Markdown形式でAmazon S3に保存。ナレッジベースのベクトルデータをS3 Vectorsへ取り込んだ。Amazon OpenSearch ServerlessやAmazon Auroraと比べて運用負荷とコストを抑えられる選択だ。
リリース後のLLMOpsも組み込んだ。AgentCoreの実行履歴がAmazon CloudWatchに送られるため、利用状況の分析と性能評価が可能になる。「AIサービスは公開して終わりではありません。ユーザーから得られるフィードバックを基に継続的に改善し、本当に価値のあるアプリケーションへ成長させていくことが重要です」という御田氏の言葉は、運用フェーズを最初から設計に組み込んでいることを示している。
ここからは見方だが——「技術ではなくユースケース」という言葉の重み
御田氏の講演で最も印象的な発言がある。「現在、最も難しいのは技術そのものではありません。AIエージェント開発における最大の課題は、技術ではなく、実際の業務で価値を生み出すビジネスユースケースを見つけることです」。
これは謙遜でも自戒でもない。構造的な観察だと思う。
フレームワークが整備され、ローコードツールが登場し、参考実装が出揃ってきた今、「どう作るか」の技術的ハードルは実際に下がっている。残る難所は「何を作るか」——つまり、業務の中から本当に価値が出るユースケースを見つけ、それをUXとして形にする能力に移行しつつある。
「バイブ商談」という御田氏の取り組みは、この問いへの実践的な答えだ。顧客から要件をヒアリングしながら、その場でデモアプリを開発する。「AIエージェントをプレゼン資料の中だけに存在する"伝説の生き物"のように捉えている方も少なくありません」という指摘は刺さる。動くものを見せることで、顧客が「本当に実現したいこと」を引き出せる。AgentCoreとAWS AmplifyをIaC構成で組み合わせることで、プロトタイプをそのまま商用利用へ発展させられる点も現実的だ。
「パワボ作るマン」も同じ文脈にある。作成したい内容を指示するだけでプレゼン資料を生成するAIエージェントで、チャットUIで操作できる。複雑なスライド編集機能はあえて搭載せず、AgentCore Memoryは使わずセッション機能で短期的な記憶管理に絞った。この「削ぎ落とし」の判断が、リリースから3ヶ月でユーザー数1000人超、累計トレース数7000件という結果につながっている。
実務的な示唆——開発者・プロダクト担当は何を見るべきか
re:InventエージェントとパワボくんMの事例から、実務に落とせる判断軸が見えてくる。
シングルエージェント構成から始めること。マルチエージェントは後から複雑さを追加できる。逆はしにくい。PoCやMVPの段階では、ツールを1つのエージェントに集約し、制御ロジックをシンプルに保つことが後工程の拡張性につながる。
UXの設計をインフラ同様に扱うこと。御田氏が強調するのは「ユーザーが待っている時間の体験」だ。エージェントが現在どの処理を実行しているかを途中経過として表示し、不安やストレスを軽減する。ストリーミングレスポンスの実装は難易度が高いが、リアルタイム性が求められるAIエージェントでは後付けが難しい設計ポイントだ。
コスト最適化を後回しにしないこと。御田氏は、用途に対して過剰な性能のLLMを選ばないこと、Claudeのプロンプトキャッシュの活用、会話履歴を直近3往復分に自動制限することを具体的に挙げている。トークン消費はサービスが成長するほど逆説的にコストの爆発リスクになる。設計初期から意識する必要がある。
LLMOpsを最初から組み込むこと。AgentCoreの実行履歴をCloudWatchに流す仕組みは、運用開始後の改善速度に直結する。「公開して終わり」では価値を積み上げられない。
次に問題になるのはどこか
御田氏が「2025年はAIエージェントを『利用』する年、2026年は『構築』する年にしましょう」と締めくくったのは、現状認識として正確だと思う。ただ、「構築する年」になったとして、次に何が問題になるかも見えてくる。
ひとつは、ユースケース不足の問題だ。技術的ハードルが下がると、「とりあえず作ってみた」エージェントが大量に生まれる。しかし動くことと、業務で価値を出すことは別だ。御田氏自身が「最大の課題はユースケースを見つけること」と言っている通り、ここの解像度を上げる方法論はまだ確立されていない。
もうひとつは、評価と観測の問題だ。re:InventエージェントはCloudWatchでトレースを取っているが、「エージェントの応答が業務で役立ったかどうか」の評価は単純なログ集計では測れない。LLMOpsのツールが整備される一方、「何を評価すれば良いか」の問いは依然として難しい。
そしてコストだ。パワボ作るマンが3ヶ月で1000ユーザー・7000トレースに達したことは成功指標として示されているが、その規模でのコストが持続可能だったかどうかは語られていない。コスト最適化の工夫が「うまくいった」のか「必要に迫られた」のかは、スケールを想定する際の重要な情報だ。
技術の整備が先行し、使いこなしが後から追いかける——これはAIに限らず、あらゆる新技術の普及パターンだ。御田氏の講演が示しているのは、その追いかけがようやく現実的な速度になってきた、ということだと思う。「構築元年」という言葉を宣言として受け取るより、「今からでも追いつける起点」として読む方が実用的だ。
