こんにちは、Insight Edgeでエンジニアをしている島田です。 現在は社内向けのAIエージェント基盤(名前はLoom)を開発しているため、AIエージェントの開発に携わっている方や社内でエージェント基盤の内製を検討している方へ向けて、エージェント基盤の設計の考え方と内製の判断について紹介したいと思います。 記事を通して書いているのは、汎用エージェントはWebアプリケーションと違ってAPIの形が案件によらず収束するため、案件ごとに変わる部分だけを拡張ポイントとして外に出せば基盤化できる、という話です。 本記事はAIエージェント開発の経験を前提としていないため、前半で汎用エージェントの構造から説明します。実装の詳細にはあまり踏み込まず、設計の考え方や内製の判断に関わるトピックを中心に書いています。 目次 目次 導入背景 汎用エージェントを社内エージェント基盤にする 汎用エージェントの構造 エージェントが基盤化に向いている理由 ワークフロー型から自律型へ 設計パターンの収束 Loomのアーキテクチャと拡張ポイント カスタムツール 基盤に入れるものと入れないものの設計判断 エージェントフレームワークを使うべきか Claude Agent SDK・Managed Agentsと内製基盤 SDKが引き受けるのはハーネスの部分だけ 案件駆動のカスタマイズに即応できる セキュリティ境界を自社内で完結できる 今後の展望と課題 Developer adoption 評価プロセスの型化 モデルの進化と基盤の賞味期限 導入背景 Insight Edgeは住友商事やグループ会社の内製開発組織としてDXコンサルティングやシステム開発をしています。案件は3ヶ月程度のPoC中心で、その後に商用化というパターンがほとんでです。ここ最近の案件はほとんどが生成AI関連で、中でもエージェント案件の比率が上がっています。エージェントの守備範囲と精度が広がってきたことがそのまま案件数に反映されているのだと思います。 一方で開発の実態としては下記のような課題がありました。 APIはFastAPI、フロントはReact、IDaaSはEntra ID/Identity Platform、インフラはCloudRun、エージェントフレームワークはADKなど、案件によって多少違いはあれど似たような技術スタックでゼロから組んでいる PoCで作ったものを商用レベルに仕上げていく過程で、商用レベルのインフラ設計・構築、セキュリティ、オブザーバビリティ、デプロイパイプラインといった非機能面の作り込みを毎回繰り返している 案件にアサインされる開発者は1〜2名程度のため、そこで得た知見が個人の中にしか残らない プロダクト開発であれば同じコードベースに複数人が長期間関わるため自然に知見が溜まっていきますが、1〜2名で3ヶ月のPoCを回して次の案件へというサイクルだと、隣の案件で誰かが同じ実装で同じようにハマっていても気づく機会がありません。私は基盤・ソリューション開発以外の通常案件にも入るため、同じものを何度も作っている感覚が毎回ありました。 汎用エージェントを社内エージェント基盤にする エージェント基盤を作り始めたきっかけは、まだClaude Codeにサブエージェントが登場したくらいの頃にアンケート結果を分析して組織改善の示唆を出すというPoCをClaude Codeで行ったことです。案件固有の作り込みはプロンプトとサブエージェントを軽く用意した程度で、しかもそれ自体もClaude Codeに作らせたものでしたが、アウトプットの質は想定よりかなり高いものでした。汎用のエージェントがそのまま業務のアウトプットに使えるという感触をこのときに持ちました。 上記のPoCもそうですが、弊社のPoCにはユーザーが使うシステムまでは作らず、アウトプットの品質が業務で通用するかどうかだけを検証するものも多いです。Claude Codeの利点はこういった短い期間のPoCでシステム開発をせずに案件の課題解決に集中できることですが、PoCでClaude Codeを使って良い結果が出たとしても、商用化の段階では同等の品質で動くエージェントを自分たちで作らなければなりません。 そんな背景から、社内勉強会で「Claude CodeのCloud版のようなものを作ってみる」という趣旨でプロトタイプを作り、先述のアンケート案件の商用開発に組み込みました。PoCのときに作ったプロンプトやサブエージェントをそのまま移植したところ、Claude Codeと変わらないアウトプットが出てきたため、これを基盤化すれば上記の課題がまとめて解決できるなと思うようになりました。このプロトタイプを案件から独立させ、社内向けのエージェント基盤として開発しているのがLoomです。現在はPdMと私を含めたエンジニア3名弱のチームで開発しています。 汎用エージェントの構造 まず汎用エージェントがどういう仕組みで動いているかを整理しておきます。 Claude Codeのようなものと聞くと複雑なものを想像されるかもしれませんが、コアの部分がかなりシンプルなので自作は思っているより簡単です。実際、汎用エージェントの中核は擬似コードで書くと下記だけです。 # エージェントが使えるツール群。それぞれはただの関数(後述) TOOLS = { "bash" : bash, "read_file" : read_file, "write_file" : write_file} messages = [system_prompt, user_message] while True : # LLMに使用可能なツールの一覧を渡してユーザーの要求に応えるには次にどのツールを使えばよいか考えさせる response = llm.generate(messages, tools=TOOLS) # ツールを呼ばなくなった = 仕事が終わったということ if not response.tool_calls: return response.text messages.append(response) # LLMが返してくるのは実行したいツールの名前と引数だけで、実際に関数を呼ぶのはアプリケーション側 # 例: response.tool_calls == [{"name": "read_file", "arguments": {"path": "/tmp/a.txt"}}] for call in response.tool_calls: result = TOOLS[call[ "name" ]](**call[ "arguments" ]) messages.append(result) ポイントは、LLM自体はツールを実行しないことです。LLMが返すのは呼びたいツールの名前と引数だけで、実際に関数を呼ぶのはアプリケーション側になります。その結果を会話履歴に追加してもう一度LLMを呼び出して考えさせる、というのをツールを呼ばなくなるまで繰り返し、ツールを呼ばなくなった時点がエージェントとして仕事が終わった時点です。 TOOLS に登録する関数も特別なものではなく、下記のような通常の関数です。 def read_file (path: str ) -> str : """指定されたパスのファイル内容を返す""" return open (path).read() この関数の戻り値がそのまま会話履歴に追加され、LLMはその内容を踏まえて次にどのツールを使うか、あるいはもう十分なので回答するかを考えます。 LLMに渡すのは関数の実装ではなく、関数名と引数の定義(シグネチャ)とdocstringだけです。これがそのまま「このツールが何をするものか」の説明になり、ツールの定義はシステムプロンプトと一緒に毎回のリクエストで送られます。つまりLLM側から見えているのは自然言語で書かれた関数の説明の一覧で、エージェントの賢さの本体はモデル側にあります。アプリケーション側が持っているのは上記のループとツール群、それに会話履歴が長くなりすぎたときに要約して詰め直す仕組みくらいです。 もちろん、これを業務で使えるものにするには周辺の作り込みが必要になります。ただし大変なのはループの中身ではなく、その周辺です。ループ自体はClaude Agent SDKのようなものを使えば自分で書く必要すらありませんが、下記は結局自分たちで用意することになります。 誰が使えて、何を実行してよく、いくら使えるのか(認証・認可・利用量の制限) エージェントが実行するコードをどこで動かすのか(サンドボックス) 数分から数十分かかる実行をどう捌くのか(APIサーバーとワーカーの分離、キューイング、オートスケール、進捗をUIへ返す経路) 会話履歴や成果物をどこに保存し、ユーザーごとにどう一覧・再開させるのか(DBとAPI) ユーザーが触るUI そして、これらは案件ごとにほとんど変わりません。 エージェントが基盤化に向いている理由 Web系の案件では共通基盤や社内共通フレームワークの類はあまりうまくいかないという印象を持っています。理由はAPIが案件の要件ごとにバラバラだからです。在庫管理システムと営業支援システムではエンドポイントやドメインモデル、UIまで異なるため、共通化できるのは認証まわりとプロジェクトの雛形くらいで、アプリケーション本体は毎回書くことになります。無理に共通化しようとすると、あらゆる案件の要望を吸収するための設定項目が増え続け、結局誰も把握できないものになりがちです。 一方、汎用エージェントの場合、アプリケーションのAPIは下記のようなものに収束します。 エージェントを実行する スレッド(会話セッション)の一覧・詳細を取得する、再開する 実行中の進捗を受け取る 生成された成果物を取得する 実行を中断する 在庫管理のエージェントでも営業支援のエージェントでも、この形は変わりません。案件ごとに異なるのは「エージェントに何をさせるか」、つまりプロンプト、ツール、ナレッジの部分だけです。 Webアプリケーション 汎用エージェント APIの形 案件ごとに異なる ほぼ同じ形に収束する 案件ごとに変わる部分 アプリケーション全体 プロンプト・ツール・ナレッジ 基盤化できる範囲 認証・雛形程度 API層・実行基盤・インフラのほぼ全部 つまり、API層と実行基盤とインフラを基盤として固定し、案件ごとに変わる部分は拡張ポイントとして外に出したうえで管理画面から設定できるようにすれば、基盤と案件固有部分を分離できます。案件チームは基盤のコードを触らず、管理画面からプロンプトやツールを登録するだけで案件固有のエージェントを組み立てられる、という形が理想です。これがLoomの前提にしている考え方です。 ワークフロー型から自律型へ もう一点、この考え方の前提になっている変化があります。 Loomを作り始めた当時のLLMアプリケーションの主流は、処理の流れをワークフローとして人間が設計し、その一部にエージェントティックな要素を組み込むという作り方でした。当時のエージェントフレームワークも、ワークフローをどう記述するかに主眼を置いたものが多かったと思います。 ただ、開発でClaude Codeを使っているうちに、モデルが賢くなるほど人間がワークフローを組んでやる必然性は下がっていくと感じるようになりました。分岐や手順を人間が固定するのはモデルの判断力を信用しないということなので、モデルの判断力が上がるほどそれ自体が制約になります。逆に自律的な汎用のエージェントループが主体であれば、案件ごとに変わるのはプロンプトやツールの部分だけになります。 とはいえ現場には「この業務は決まった手順で実行させたい」という要求も一定あります。その場合も案件ごとにワークフローをアプリケーションとして作り込むのではなく、フローだけをyamlファイルやコードとして外出しすることで解決できます。今であればdynamic workflowsがそれにあたり、Loomにもこの仕組みを取り込みました。 ※ dynamic workflowsが生まれた背景自体は固定フローの需要ではなく、複雑なタスクを途中で完了にしてしまう・自分が出力の検証が甘い・コンテキスト圧縮を繰り返すうちに当初の目的からずれていく、といったエージェントループの弱点への対処です。ワークフローという言葉が戻ってきてはいますが、フローを書く主体が人間からエージェントに移っている点が従来のワークフロー型とは違います。仕組みとしては同じもので、人間が事前に書いたフローもエージェントがその場で書いたフローも同じように実行できます。 設計パターンの収束 さらに、汎用エージェントの設計パターンが業界的に収束していることも基盤化を後押ししました。 LangChainのDeepAgentsやOpenAIのCodexも、サブエージェントやスキルといったClaude Codeと同じ構成要素を備えており、スキルに至ってはSKILL.mdがオープン仕様として公開され各社のエージェントに採用されるところまで進んでいます。汎用エージェントの構造はある程度一定の形に落ち着きつつあり、設計が収束しているということは基盤としてその構造を固定してもしばらくは陳腐化しないということでもあります。 Loomの設計にあたっては、ManusやAnthropicが公開しているエージェント設計に関する記事を参考にしたり、Claude Codeのシステムプロンプトと挙動の観察から内部の仕組みを推測して取り込むということをやっています。Loomのサブエージェント機構が「サブエージェントを起動するツールが1つある」という形になっているのもこの観察から来ています。 Loomのアーキテクチャと拡張ポイント Loomの構成は下記のようになっています。 Loomアーキテクチャ チャットUIからエージェント実行を投げると、キューを経由してワーカーがエージェントループを回します。エージェントの実行は数分から数十分に及ぶこともあるため、APIサーバーとワーカーを分けて非同期に処理し、進捗はストリーミングでUIに返しています。エージェントがシェルを実行したりファイルを読み書きしたりする場所として、ユーザーごとにサンドボックスを払い出します。インフラはKubernetes上に構築しており、案件ごとにテナントを分離できるようにしています。 基盤としては下記を共通化し、案件開始後にすぐに環境を払い出して利用できるようにしています。 認証 UI API (スレッドやメッセージ取得、サブエージェントやツールのCRUDなど) エージェント インフラ サンドボックス デプロイパイプライン このうちUIは必須でなく、APIだけの利用も可です。案件側で専用のUIを作りたい場合や、既存のシステムからエージェントを呼び出したい場合は、Loomをバックエンドとして使う形になります。 そして案件ごとに変わる部分は、下記の拡張ポイントとして外に出しています。 拡張ポイント 内容 主に作る人 プロンプト 定型プロンプト 案件チーム / ユーザー サブエージェント プロンプトと使用可能ツールのセット 案件チーム / ユーザー Skill Agent Skill 案件チーム / エージェント自身 / ユーザー ワークフロー 決まった手順を固定するためのフロー定義 (スクリプト) 案件チーム / エージェント自身 / ユーザー カスタムツール エージェントに与える案件固有のツール関数 案件チーム MCP 案件固有またはサードパーティMCPサーバー 案件チーム いずれも基盤のコードを変更せず、再デプロイもせずに追加できます。サブエージェントなどはClaude Codeなどのエージェントと基本的に同じため、ここではカスタムツールだけ説明します。 カスタムツール bashやファイルの読み書きなどの基本的なツールはリポジトリに入れてありますが、案件固有の処理を書いたツールは基盤側のリポジトリに入れるべきではないため、外部から拡張可能な形にしています。 下記のような関数を管理画面から登録すると、実行時に動的にツールとして読み込まれます。 def search_product_master (keyword: str ) -> dict : """商品マスタを検索して、該当する商品の一覧を返す""" resp = httpx.get(f "https://internal-api.example.com/products?q={keyword}" ) return { "status" : "success" , "products" : resp.json()} 登録した時点で次のリクエストからエージェントがこのツールを使えるようになり、基盤の再デプロイもプロセスの再起動も不要です。 案件固有のDBや社内APIに繋ぐだけであれば、MCPサーバーを立てるよりこちらのほうが手軽です。MCPの場合はサーバーを実装してデプロイし、その後の運用も抱えることになりますが、カスタムツールは関数を1つ書いて管理画面から登録するだけで済みます。シークレットは別途登録できるようにしており、ツール関数内から参照できるようになっています。 基盤に入れるものと入れないものの設計判断 基盤に何を入れるかの判断基準は案件固有のものかどうかの一点ですが、これは言うほど自明ではなく、そもそも汎用化して取り込める形にできるのか・既存の概念や拡張ポイントに寄せられないか・取り込むだけの価値があるか・将来的に負債にならないか、などを考えなくてはいけません。 ある案件で「エージェントにペルソナを与えてRAGチャットボットとして使いたい」という要望がありました。噛み砕いてみると、基盤だけでは完結しない部分として下記があるとわかりました (他にもありましたがここでは3個だけ)。 ファイル操作やシェルコマンドは必要なく、むしろ塞いだ方がいい ペルソナを持ったエージェントを複数作りたい。UIから質問を投げる(メイン)エージェントを切り替えられるといい ペルソナにナレッジを持たせるためにRAGしたい 1は一見すると特定案件の都合ですが、サンドボックスを使うツールをオフにしてしまえば要件を満たせることがわかり、サンドボックスレスモードを実装しました。こういったモードの分岐は、将来的な機能追加で考慮しなくてはいけない点が増えてしまうデメリットもありますが、今後RAGチャットボット案件もカバーできるメリットの方が大きいと考え基盤に取り込みました。 2は要はメインエージェントを複数定義できるようにしたいという要件です。基盤の機能としてあってもおかしくない機能ですが、取り込み方を工夫しました。既存のメインエージェントとサブエージェントどちらもシステムプロンプト内の <identity> ブロックや末尾につける追加のinstructionだけカスタマイズできればよかったため、既存のサブエージェントテーブルにカラムを追加してメインとして使うかサブとして使うかを判別できるようにしました。概念的には "エージェント" として汎化できたので、複雑さを増やさずに済みました。 3のRAGについては、案件チームが作成したベクトルDBのterraformモジュールをリポジトリに置くだけに留めました。シングルテナントでterraformのワークスペース (HCP TerraformのWorkspace) もテナントごとに分かれているため、ベクトルDBを使いたい場合はそのモジュールを他のテナントでも再利用できます。一方で、ベクトルDBへデータを投入する処理と、エージェントがそこを検索する部分は基盤に入っていません。検索はカスタムツールで繋げば済みますが、投入まで含めると案件ごとの実装が残ります。将来的には下記のように拡張できるかもしれません。 ナレッジをファーストクラスの概念として管理画面から登録できるように ナレッジ登録時にデータをベクトルDBにインポート 各エージェントがどのナレッジを参照できるかを管理画面から選択できるように 何も考えず要望をそのまま機能にしていくと、機能は増えても基盤はどんどんキメラ化していきます。汎用の基盤では、要望をどう実装するかよりも、どういう概念として取り込むかを考え、基盤チームがその判断を担っていくことが大切だと感じています。 エージェントフレームワークを使うべきか LoomはGoogleのADK(Agent Development Kit)というエージェントフレームワークの上に構築されています。作り始めた当時はエージェントループも汎用エージェントの構造も理解していなかったため、フレームワークの実装自体がエージェントの仕組みを理解する教材になりました。 一方、開発・運用していく中でフレームワークが制限になる部分もいくつか見えてきました。例えば、下記についてはADKの機能は使わず自前実装に置き換えています。 コンテキスト圧縮 - 当時はトークンベースの圧縮方式が提供されていなかった サブエージェント - ADKのAgentToolではサブエージェントのセッションやイベントが永続化されない問題あり LLMプロバイダ層(GPT/Claude) - ADKはGemini以外のモデルのサポートが薄い。内部で使っているLiteLLM自体も新モデルへの対応が遅れる場合があった また、ADKはセッションやイベントをADKが管理するテーブルに永続化してくれますが、Loomではそれとは別にスレッドやメッセージの自前テーブルを持っており二重管理になっています。 ADKの機能で使ってない部分も多く、先述の通りエージェントは中核構造がシンプルなことから、独自の永続化層やワークフロー記述まで持ち込む多機能なフレームワークに乗るメリットは思ったより小さいと感じています。長期に育てるアプリケーションであれば、エージェントループの周辺は薄く自前で持つか、後述のClaude Agent SDKのようにハーネスだけを提供するものに寄せるかのどちらかがよいのかなと思います。 一方で、3ヶ月のPoCでゼロから作るのであればフレームワークを使うのが正解かもしれません。動くものに最速で到達できますし、PoCの寿命であればロックインのコストは顕在化しません。 Claude Agent SDK・Managed Agentsと内製基盤 現在は、Claude Agent SDKやManaged Agentsなど、汎用エージェントをアプリケーションに組み込むための選択肢は充実してきています。 一方で、それらを使えば全部解決でプラットフォームが不要になるわけではありません。 SDKが引き受けるのはハーネスの部分だけ Claude Agent SDKが引き受けてくれるのは、エージェントループ、ツール実行、コンテキスト管理、サブエージェントといった、いわゆるエージェントハーネスの部分です。しかしエージェントを組織に提供しようとすると、認証とユーザー管理、テナントごとの分離、利用量の管理と上限設定、スレッドや成果物をユーザーごとに保存して一覧させるDBとAPI、長時間の実行を捌くインフラ、そしてUIが必要になります。エージェントがコードを実行するサンドボックスも自前で用意することになります。 2026年8月時点でManaged Agentsはもう少し広く、サンドボックスのホスティングやセッション状態の管理、イベント履歴の永続化までを引き受けてくれます。それでも、エンドユーザーの認証・認可、自社のユーザーとセッションの紐付け、UI、ブラウザまで届ける最後の区間は自前です。加えて企業のポリシーや扱う情報によっては結局セルフホスト型サンドボックスが必要になったり、そもそもManaged Agents自体が選択肢に入らないこともあります。 公式の選択肢を使えば基盤が不要になるわけではなく、基盤の一部が楽になるというのが正確なところだと思います。 案件駆動のカスタマイズに即応できる ハーネス部分も含めて自分たちの好きなようにカスタマイズしていける点は思ったより大きいです。先述のチャットボット案件のように、案件から出てきた要望を短期間で基盤の機能にするという動き方は内製だからできることです。 セキュリティ境界を自社内で完結できる エージェントは任意のコード実行を伴う仕組みのため、それをどこで動かすのかはセキュリティ上の重要な論点になります。住友商事のようにセキュリティ要件が厳しく、扱う情報の機微度も高い相手に対して、実行環境も含めて自社の管理下の環境で閉じていると言えることはそれ自体が価値になります。 今後の展望と課題 Developer adoption 基盤は作れば使われるというものではなく、社内で自然に使われるようにしていくことが重要です。エンジニアに絞ると、少なくとも下記のようなハードルがあるのかなと思います。 誰かが作ったものを使うより自分で開発したい そもそもLoomが何なのか、どこまでできるのかわからない 基盤やツールで大部分が完結してしまう案件はつまらない 特に3つ目は基盤が目指している状態そのものが裏目に出ています。 これらを解決するには、基盤の開発やLoom案件の対応をLoomチームに閉じず、InsightEdgeの開発者が広く開発に関われる状態を作るのがいいと考えています。基盤を開発した人が自分でもLoomを使った案件にFDE的に入り、そこで得た示唆を基盤の機能やアイデアとして戻す、というサイクルが回れば、上記の3つは同時に解消に向かいます。 この変化はInsightEdgeのエンジニアリング部全体に関わってくる話のため、社内のDevexチームやEM、リードエンジニアにも協力してもらいながら進めています。 評価プロセスの型化 LLMやエージェントの案件では、顧客の求めるアウトプットが出ているかの精度を上げていく作業が中心になります。そこで問題になるのが、同じ入力で毎回同じ品質が出るかという再現性と、プロンプトやスキルを直したときに過去のフィードバックへの対応が壊れていないかという回帰です。これを担保するのが評価で、本来はどの案件でも持つべきものですが、弊社として方法が確立できていません。 まず方法論を固めたうえで、基盤の機能としても組み込めるといいと考えています。基盤で評価すれば自然と弊社標準のプロセスに乗る、という状態が理想です。仕組みとして基盤に置くのが合理的だと思っているのは下記あたりです。 評価用データセットやルーブリックの登録。中身は案件固有でも器を共通にできる点で、他の拡張ポイントと同じ構図 データセットに対する一括実行。キューやワーカー、実行記録、コスト計上はすでにあるので、案件ごとに作るより基盤へ置くのが自然 実行時のモデルやプロンプト、スキルのバージョンを記録し、同じ条件で比較できるようにする 導入背景で挙げた「知見が個人の中にしか残らない」という課題は、アプリケーションの実装だけでなくこの部分にも当てはまります。案件で得た評価の観点が基盤の上に残れば、似た業務の案件で型として再利用できます。 モデルの進化と基盤の賞味期限 エージェント案件が増えている根本の原因は、モデルの守備範囲と精度が広がり続けていることです。これは裏を返せば、モデルの欠点を補うために書いたコードは、モデルが賢くなるほど不要になっていくということでもあります。振り返ると、まずClaude CodeやDeep Agentsのようなハーネスが登場し、今はそこにインフラをバンドルしたManaged Agentsのような形が出てきています。 エージェントを「ビジネスロジック + ハーネス + インフラ」の3層に分けて考えてみると、このうちハーネス層はコンテキスト管理やメモリのようにモデルの欠点を補う性格が強いため、モデル側の進化とともに吸収されていくかもしれません。インフラ層も本記事で書いてきたように収束しているからこそ遠からずコモディティ化していくと思います。 最後まで残るのはビジネスロジック層だと思います。プロンプト・スキル・ツール・評価データセットとして蓄積された業務知識は、モデルがいくら賢くなっても誰も肩代わりできません。そしてAGENTS.mdやskillsといった標準仕様の普及によって、特定のハーネスや基盤から独立したポータブルな資産になりつつあります。 Loomも、将来的にはハーネスとインフラが置き換わり、ビジネスロジック層しか残らないかもしれません。それでも、業務知識を移植可能な形式で蓄積する取り組みを今の時点から続けておけば、実行エンジンが何に置き換わっても資産と運用の型はそのまま持ち越せます。モデルの進化で何が消え、何が資産として残るのかを念頭に、どの層に投資し、どの層はいつでも捨てられるようにしておくかという視点で基盤の戦略を立てていくことが重要だと考えています。 以上、本稿がAIエージェント基盤の設計や内製の判断の一助になれば幸いです。

1. はじめに RAGでは、検索でヒットした複数のチャンクをそのままLLMのプロンプトに詰め込むことがあります。しかし検索結果には質問と無関係な文章も含まれており、コンテキストが大きくなるほど入力トークンが増え、コストやレイテンシにも影響します。 この課題への対策として提案されているのが Query-aware Compression（クエリを考慮した圧縮） です。本記事では、この手法を日本語FAQで実際に動かし、「トークンとコストは本当に削減できるのか」を実測で検証しました。 結論を先にお伝えすると、Sonnetへの入力トークンは最大94.2%削減でき、入力・出力の両方を含めたコス

1. はじめに ! 要約/結論 Amazon Bedrock Agents は Amazon Bedrock Agents Classic に名称変更され、メンテナンスに移行しました（既存利用者は継続利用可） Bedrock Agents Classicの代替としてAmazon Bedrock AgentCore上に新しいAIエージェントを構築する場合、AgentCore Harness（設定中心）とAgentCore Runtime（コード中心）が主な選択肢になります。 本記事では AgentCore Harness を実際にデプロイし、Memory・ログ・exportによる A