はじめまして。 金融IT本部 プロダクトソリューションユニット 融資ソリューション2部の 渡邉 真太郎 です。 現在は 2 年目社員として、地域金融機関向けの CRM / SFA サービス開発に従事しています。 2025 年 11 月、Anthropic がエンジニアリングブログの記事（ Effective harnesses for long-running agents ）のタイトルに「ハーネス（harness）」という言葉を掲げました。長時間動き続ける AI エージェントを、いかに破綻させずに走らせ続けるか——その「型枠」や「足回り」にあたる仕組みを指す言葉です。 公開直後から、この言葉は一気に界隈を駆け巡りました。「これからはプロンプトエンジニアリングではなくハーネスエンジニアリングだ」といった論調があちこちで見られ、SNS や技術記事のタイムラインは、しばらく「ハーネス」一色だったように思います。 それから半年経ち、当初のバズワード的な過熱はいくらか落ち着きましたが、「ハーネス」は一過性の流行語として消えるどころか「ハーネスエンジニアリング」という一つの設計分野として、むしろ業界に定着しつつあります。 だからこそ今、流行り言葉としてただ持ち上げるのではなく、「 結局ハーネスとは何なのか 」を地に足をつけて理解したいと考えています。 そこで本記事では、ちょっとした検証も交えながらハーネスという概念を改めて整理してみたいと思います。 本記事は、隔週で開催している社内勉強会『25卒技術会』での発表内容をもとに執筆されています。 前回の記事 はクロスイノベーション本部の大岡叡さんが書いています！ぜひご覧ください！ Part 1. ハーネスの概要を知る 1-1. ハーネスの文脈 1-2. ハーネスの定義 Part 2. より詳しく理解する 2-1. ハーネスを体系的に理解する難しさ 2-2. ハーネスの体系的分類 メインとして扱う分類：Meng らの6成分（ETCSLV） 2-3. ここまでのまとめ Part 3. 自分で検証する 3-1. 検証方法 E（実行ループ）: 一時的な失敗からの復帰 T（ツール）: 反復作業を助ける Skill C（文脈管理）: どれが正しい資料かを教える S（状態）: セッションを跨ぐ引き継ぎ L（フック）: 完了前の関門 V（評価）: 別のエージェントによる点検 3-2. 各成分のタスクとハーネス（一覧） 3-3. 確認指標と実験条件 3-4. 結果 Part 4. 学びを整理する 4-1. ベストプラクティスは「そのまま従う」ものではない 4-2. モデルが進化しても効くのは「知識を補う」ハーネス 4-3. Haiku ですら、もう十分に賢い まとめ：ハーネスは「盛る」より「効かせる」 これからのハーネス Part 1. ハーネスの概要を知る 本 Part では、そもそも「ハーネスという言葉すら聞いたことない」という方向けに、 ハーネスの文脈（なぜ生まれたか？） ハーネスの定義（どういう意味の言葉か？） を説明します。 1-1. ハーネスの文脈 AI に仕事をさせるとき、私たちが作り込む対象はここ数年で少しずつ移り変わってきました。 モデルへの指示そのもの から、 モデルに渡す情報 、さらには モデルを取り囲む仕組み へと、工夫する領域が広がってきたイメージです。 プロンプトエンジニアリング ：モデルへの「言い方」を工夫する コンテキストエンジニアリング ：モデルに「何を見せるか（文脈）」を設計する ハーネスエンジニアリング ：モデルの 周り に、計画・記憶・検証・復旧などの 機構 を組む はじめは一問一答が中心で、いかに上手く指示するか（＝プロンプト）が工夫のしどころでした。やがて扱うタスクが大きくなり、検索結果や長い資料をモデルに渡すようになると、限られた文脈に何をどう載せるか、いわゆる「コンテキスト」が問われるようになっていきました。 そして AI エージェントという自律的処理機構の台頭により、上記の工夫だけでは足りなくなった結果生まれたのが「ハーネス（エンジニアリング）」という言葉です。 ちなみに「ハーネス（harness）」はもともと 馬具 を指す言葉で、馬（＝モデル）を制御して仕事をさせる装具、という比喩です。 1-2. ハーネスの定義 次に、ハーネスの厳密な定義に目を向けていきます。 …が、多くの IT 系ホットワードの例に漏れず、「ハーネス」という語もコミュニティで盛んに利用される割に、業界統一での定義はされていません。 よってここでは、多くの一次情報で登場する言葉の使われ方を 2 点程ご紹介します。 エージェント = モデル + ハーネス モデルとは、"Claude Opus" や "GPT" などの「AI 本体」の部分です。 ハーネスはこの周りでモデルを動かし続ける仕組みであり、モデルとハーネスを組み合わせることによってエージェントが成り立っている、と多くの文献では定義されます。 乱暴に簡易化すると、「AI エージェントのうち、 モデル以外のすべて がハーネスである」ということです。 狭義のハーネス 前述の「モデル以外の仕組み」をもう少し分解すると、下記の二つに分けられます。 AI エージェントを走らせる 前 に組んでおく設定: system prompt、ツールの説明、文脈の渡し方など AI エージェントが走っている 最中 に効く機構: ツール呼び出しの処理、文脈の圧縮、安全制約の強制、状態の永続化など このうち前者を scaffold（足場） 、そして後者を狭義としての harness（ハーネス） と呼び分けることがあります。 特に前者がより浸透しているハーネスという語の使われ方だと個人的には感じています。 よって本記事でも、「モデルと共にエージェントを構成する要素（モデル以外のすべて）」という 広義のハーネス を指して、以降「ハーネス」と呼んでいきます。 Part 2. より詳しく理解する 次に、「ハーネスとは何か」をより具体的に整理します。 ハーネスという語はその話題性に反し、概念を深く理解する上でいくつかの障壁が存在します。 ここではまず、その前提となる難しさを整理してから、ハーネスの体系的な理解を試みます。 2-1. ハーネスを体系的に理解する難しさ ハーネスを腰を据えて理解しようとすると、最初に2つの壁にぶつかります。 (1) デファクトの分類が無い ハーネスは非常に広い概念なので、全体像をつかむには「どんな要素からなるののか」という体系・分類が肝要です。 ところが、Anthropic や OpenAI といった各社は、AI エージェントの設計・運用に関する個別のベストプラクティスを数多く公開しているものの（例：Anthropic: Harness design for long-running application development 、OpenAI: Harness engineering など）、「ハーネスとはこう分類される」と断定的には整理しておりません。 結果として、多くの有志が「AI モデル以外のチューニング要素＝ハーネス」という大枠のもとに独自の体系を作っており、 複数のサイトを覗くと、どれも少しずつ違う分類になっている というのが現状です。 (2) 概念が流動的 ハーネスは「モデルを補助する機構」という性質上、モデルが賢くなるほどベストプラクティスが移り変わります。 Anthropic 自身、 記事 の中で 「 ハーネスの各部品は、モデルが自力でできないことについての"仮定"を符号化している。その仮定は誤っているかもしれず、モデルの改善とともに急速に陳腐化しうるので、検証する価値がある 」　　 と述べています。 実際、同社はあるモデル世代で必須だった「コンテキストのリセット機構」を、次世代では丸ごと外せたと報告しています。 つまり 固定的な分類を作りにくく、個々のベストプラクティスを継続的に追いかける必要がある 、というわけです。 この2つを踏まえ、それでも全体像をつかむために、本記事では「 現時点の代表的な分類を1つ選び、それを軸に他の分類を読み解く 」という進め方をとります。 2-2. ハーネスの体系的分類 メインとして扱う分類：Meng らの6成分（ETCSLV） 本記事では、ハーネスを正面から形式的に分解した最新のサーベイ（ Meng et al. "Agent Harness for LLM Agents: A Survey" ）が提案する 6つの成分 をメインの分類方法として利用します。ハーネスを H =（E, T, C, S, L, V） の6成分に分けるもので、それぞれの役割は次のとおりです。 記号 成分 役割（何をするか） 具体例 E 実行ループ 次の手を決め→実行→観測を繰り返し、いつ止めるかを司る 「考える→操作する→結果を見る」を回す ReAct 型ループ。Claude Code が編集とテスト実行を延々と回す動き T ツール モデルが外界にできること（行動の選択肢） ファイル読み書き・シェル・テスト実行、MCP 接続、Skills C 文脈管理 何を見せ、作業中の文脈をどう保つか 関連資料を全部渡す（dump）か必要時だけとる（JIT）か、長くなったら要約する S 状態 会話の外に何を残し、セッションを跨いで引き継ぐか 進捗ファイル、 state.json 、Git 履歴、次セッションへのハンドオフ L フック 節目で決まった処理を強制的に発火させる 「完了の前に必ずテスト/型チェックを通す」ゲート、起動時の init.sh V 評価 成果物が要件を満たすか・終えてよいかを判断する 別エージェントによる要件照合と差し戻し、テストでの合否判定 この分類に当てはめると、例えばプロンプトの調整は C（文脈管理） 、会話内容のログ化は S（状態） 、一時期話題になった "evaluator エージェントの起用" は V（評価） として分類されるハーネスです。 これは 要素の切り分けが最も明示的 で初学者でも考えやすく、またそこそこ 網羅的である 点が非常に優秀です。 よって本記事ではこの分類を基準として扱い、ほかの分類を読み解いていきます。 ※ ただしこれは、 業界で確立した標準ではなく、あくまで最近の代表的な分類の一つ である点には注意してください。また場合によっては上記の分類で適切に分離できないものもあります。 6成分以外にも、代表的な分類がいくつかあります（Wang らの4モジュール、実装解析の "Inside the Scaffold" 12次元、Anthropic / OpenAI の実装パターン、コミュニティの整理など）。 それぞれの詳しい説明に努めたいところですが、本記事では文量の関係で上記の 6成分を基準 にして検証へ進みます。 参考：6成分以外の分類例と、6成分との対応（クリックで展開） (1) Wang らの4モジュール（エージェント構築の統一フレームワーク） A Survey on LLM based Autonomous Agents （Wang et al.）は、エージェントを profiling／memory／planning／action の4モジュールで整理する統一フレームワーク（unified framework）です。ハーネスに特化した分類ではなくエージェント全般が対象で、6成分より粒度は粗めです。 (2) Inside the Scaffold の12次元（実装の実態） Inside the Scaffold （Benjamin Rombaut、※査読前）は、実在する13個のコーディングエージェント（OpenHands・SWE-agent・Aider・Cline・Codex CLI など）のソースコードを解析し、設計を 制御アーキテクチャ／ツール・環境のI/F／リソース管理 の3層・12次元で比較します。「ツールが使える」「記憶がある」といった能力レベルの抽象分類では見えない 実装の差 が、コスト・信頼性・失敗の出方に直結する、と指摘します。 (3) 各社の実装パターン（Anthropic / OpenAI） Anthropic は長時間のアプリ開発で、 initializer＋coding agent の2エージェント（ Effective harnesses for long-running agents 、Justin Young）から、 planner・generator・evaluator の3エージェント（ Harness design for long-running application development 、Prithvi Rajasekaran）へと発展させました。sprint contract（着手前に"完了の定義"を合意）/ context reset / 評価者の分離などが登場し、「 各構成要素はモデルにできないことの"仮定"を符号化しており、ストレステストする価値がある 」という一節は本記事の検証の出発点でもあります。 OpenAI も Codex を題材にハーネスを扱っています。エージェントループを解剖した記事では、Codex の中核を「 core agent loop and execution logic（中核の実行ループと実行ロジック） 」＝ハーネスと定義しています（ Unrolling the Codex agent loop ）。さらに、この設計の営みを「 ハーネスエンジニアリング 」と名づけ、エンジニアの仕事の中心が「コードを書く」ことから「 エージェントが信頼して働ける環境とフィードバックループを設計する 」ことへ移る、と位置づけています（ Harness engineering 、Ryan Lopopolo）。 (4) コミュニティ／実務の整理 有志のまとめや実務家の設定は、E/T/C/S/L/V のような形式分解ではなく、「 解きたい課題ごと 」（メモリ／評価／文脈の渡し方／ガードレール（安全・権限）／観測性／オーケストレーション…）でカテゴリを切る傾向があります。awesome-agent-harness 系のまとめや、実務家のエージェント最適化設定（例：ECC）が代表例。形式分解では埋もれがちな 権限・安全や観測性 を、独立した関心事として前面に出すのが特徴です。 2-3. ここまでのまとめ ここまで「ハーネスとは何か」「どんな要素に分けられるか」について整理してきました。そのうえで強調したいのは、 ハーネスの実装一つ一つは、決して目新しいものではない ということです。 私たちが普段からやっているプロンプトの調整、使うモデルの切り替え、Claude の Skills の利用、 CLAUDE.md でのフォルダ構成や規約の記述などはすべて、すでにハーネス設計の一部です。つまりハーネスに対しての「今までになかった全く新しい概念」という理解は正確ではなく、「 これまで AI モデルの周りで個別にやってきた工夫を、統一的に呼ぶための言葉 」と捉えるのが実態に近いと言えます。 Part 3. 自分で検証する ここまでで、ハーネスの体系をひととおり整理してきました。とはいえ、多くの方が本当に気になるのは「ハーネスを設定すると、AI エージェントの仕事は実際どれだけ良くなるのか」という点だと思います。 そこで本 Part では、Part 2 で選んだ 6成分（ETCSLV）を軸に、実際に手を動かして行った検証の結果を紹介します。 3-1. 検証方法 やったことはシンプルで、「代表的なハーネスを実装し、AI エージェントのタスク処理能力が実際に上がるかを試す」というものです。 6成分それぞれについて、その成分にあたるハーネスと、そのハーネスが効きそうなタスクを1つずつ用意しました。そして同じタスクを「ハーネスなし（素の構成）」と「ハーネスあり」で解かせ、どれだけ差が生まれるかを比べます。実行するモデルは、強いモデル（Claude Opus 4.8）と弱いモデル（Claude Haiku 4.5）の2種類です。成果物の良し悪しは、モデルには見せない隠しテストで機械的に採点しました。 題材は主に、口座開設・入出金・送金といった機能を持つ小規模な銀行コアサービス（TypeScript）で、一部はより小さなユーザー登録 API を使っています。 なお、今回試したハーネスはどれも、Anthropic が公開しているベストプラクティスに基づいています。各成分の説明で根拠として触れるのは、主に次の記事です。 Building Effective AI Agents How we built our multi-agent research system Effective context engineering for AI agents Effective harnesses for long-running agents Harness design for long-running application development 以下、各成分にどんなタスクとハーネスを用意したかを見ていきます。 E（実行ループ）: 一時的な失敗からの復帰 E で解かせるのは、小さなユーザー登録アプリの入力チェックを1つ追加する、という修正タスクです。 仕掛けはテスト実行のタイムアウトにあります。エージェントには修正後に走らせるテストを与えていますが、このテストは最初の1回だけ、強制的にタイムアウト（終了コード124）で失敗し、あたかも処理が異常終了したように見せます。 これに対するハーネスは、一時的な失敗に対するリトライの指示です。「一時的なタイムアウトで失敗しても、コードを作り変えず、まず同じコマンドをもう一度実行する」と伝えます。失敗したらすぐ諦めるのではなく、一時障害なら再試行して続ける、という実行ループの止め方の調整にあたります。 この設計は、障害対処を「モデルの適応力（ツールが失敗していると伝えれば、うまく立ち回る）＋リトライのような決定論的な安全網」で行うこと（multi-agent 記事）、そして実行ループには「制御を保つための停止条件」を設けること（Building Effective Agents）がベースとなっています。 T（ツール）: 反復作業を助ける Skill T で解かせるのは、あるアプリの複数の操作に対して、同じ形の入力チェックを1つずつ実装していく、という反復作業です。似た構造のチェックを、対象を変えながら何度も書いていくイメージです。 これに対するハーネスは、その反復を助ける Skill（Claude の拡張機能）です。チェックの骨格（雛形）を一括で生成する専用の Skill を渡し、繰り返しの手間を肩代わりさせます。ただし正解そのもの（何をどう返すか）は Skill に含めず、骨組みだけを自動化しています。 ツールや Skill でできることを広げて作業を効率化するのは基本の構成要素で、ツール（エージェントが外界にできること）の設計が成果を大きく左右する、という Building Effective Agents の立場に基づきます。 C（文脈管理）: どれが正しい資料かを教える C で解かせるのは、銀行向けの小さなアプリを仕様書どおりに直す、というチェックと修正のタスクです。ただし資料フォルダには、現行の正しい仕様書と、一見それらしい古い仕様書が、中立な名前で並べてあります。どちらが正しいかは中身からは判断できず、放っておくとエージェントは自分の常識に近いほう（標準的に見えるほう）に引きずられ、現行の仕様に反してしまいます。 これに対するハーネスは、どの資料が現行の正本かを示す情報を渡すことです。正解そのものではなく「こちらを信じてよい」という手がかりだけを添えて、エージェントの取り違いを減らします。 限られた注意の予算に、価値の高い情報を過不足なく載せる、という Effective context engineering の考え方に沿っています。 S（状態）: セッションを跨ぐ引き継ぎ S で解かせるのは、ユーザー登録アプリに項目を1つ追加する作業です。このとき、例えば入力の前後の空白をどう扱うか、といった、コードからは導き出せない細かな取り決めを、最初のセッションのプロンプトでだけ伝えます。そして作業を途中で中断し、前のやりとりの記憶を持たない、まっさらな新しいセッションで再開させます。 これに対するハーネスは、作業状態を会話の外のファイルに残しておくことです。取り決めや進捗を外部ファイル（ state.json ）に書き出し、再開時に読み戻すことで、セッションを跨いでも情報が失われないようにします。 各セッションは前の記憶を持たずに始まるため、進捗ファイルや引き継ぎ資料で状態を橋渡しする、という Effective harnesses の中核設計です。 L（フック）: 完了前の関門 L で解かせるのは、あるデータの型に必須の項目を1つ足す、という修正です。この変更を正しく行うと、本体と、テストの無い別の箇所の両方で型の不整合が起きます。ところが公開テストのほうは、型の不整合を無視してパスするよう作ってあります。そのため「テストが通った＝完了」と早合点すると、型崩れを見逃してしまいます。 これに対するハーネスは、完了前の関門（フック）です。作業を「完了」とする前に、必ず型チェックを通し、通らなければ完了させない、という決まった処理を節目で強制します。 完了の前に決まった検査を挟む「ゲート」（Building Effective Agents）と、「エージェントは十分な検証をしないまま完了と宣言しがち」という報告（Effective harnesses）が下敷きです。 V（評価）: 別のエージェントによる点検 V で解かせるのは、互いに影響し合う複数の新しい機能を、まとめて実装する大きめのタスクです。規模が大きく、ある機能の変更が別の機能に波及しやすいため、エージェントは、テストで見つかる取りこぼしを作り込みやすくなります。 これに対するハーネスは、別のエージェントによる評価です。実装を終えた成果物を、まっさらな文脈を持つ別のエージェントがレビュワーという立場で見直し、見つけた問題を直します。自分で自分の成果物を見直す「自己レビュー」と比べ、見る人を分けることの効果を測ります。 作業する側と評価する側を分けることが強力なレバーになる、という Harness design の要点に基づきます。 なお以上の6つに加え、比較の基準線として、情報の偏りが無い素直な完成タスクも用意しました。ここでは「あらゆるハーネスを常時オンにした盛りすぎの構成」が、品質を上げずにコストだけ増やさないかを確認しています。 3-2. 各成分のタスクとハーネス（一覧） 整理すると、各成分に用意したタスクとハーネスは次のとおりです。 成分 解かせたタスク 設定したハーネス E 実行ループ 入力チェックの追加（テストが初回だけタイムアウト） 一時的な失敗へのリトライ指示 T ツール 同じ形のチェックを反復して実装 骨格を一括生成する Skill C 文脈管理 仕様準拠の修正（新旧の仕様書が混在） どれが現行の正本かを示す情報 S 状態 取り決めを渡して中断→新セッションで再開 作業状態の外部ファイル保存と読み戻し L フック 必須項目の追加（型崩れ／公開テストはパス） 完了前に型チェックを通す関門 V 評価 波及の多い大きめの実装 別エージェントによる点検 3-3. 確認指標と実験条件 上記のタスクの検証に利用する指標と実験の条件についても説明します。 今回は、次の3つの指標でハーネスの効き目を見ます。 品質 （不合格数）：モデルには見せない隠しテストのうち、通らなかった数です。少ないほど良い出来で、満点はタスクごとに異なります。 ターン数 ：エージェントが「考える→操作する→結果を見る」を繰り返した数です。多いほど時間がかかります。 コスト ：1回の試行にかかったおおよその費用（米ドル）です。ターン数と並ぶ「無駄の少なさ」の目安で、使うモデルによっても大きく変わります。 また実験の条件ですが、各タスクを 「アーム（ハーネスなし／あり）」×「モデル（Opus・Haiku の2種）」の組み合わせごとに複数回繰り返しました。 反復回数は基本3回ずつ、ばらつきの大きい評価（V）だけ5回です。これらによって計測される結果の平均値をとり、分析を実施します。 各実行は毎回使い捨ての隔離環境で走らせ、前のセッションの記憶（自動メモリ）が混ざらないことを全実行で確認しました。またアーム間で「渡す情報」と「使うモデル」はそろえ、変えるのはハーネスの有無だけとし、採点も固定の隠しテストで統一して、条件をなるべくフェアに保っています。 なお満点はタスクごとに違うので、表は成分同士を直接比べるのではなく、同成分の「ハーネスあり/なし」、「モデルの差」ごとに比較します。 3-4. 結果 検証の結果は下記のようになりました。 成分（満点） モデル 不合格数（ハーネスなし） 不合格数（ハーネスあり） ターン数（なし→あり） コスト（$, なし→あり） 効果 S 状態（6） Haiku 3.0 0.0 18→21 0.08→0.12 あり S 状態（6） Opus 3.0 0.0 17→21 0.38→0.64 あり C 文脈（125） Haiku 12.3 4.7 68→77 0.71→0.71 あり C 文脈（125） Opus 21.0 0.7 37→38 2.73→2.82 あり E リトライ（4） Haiku 0.0 0.0 18→18 0.09→0.10 なし E リトライ（4） Opus 0.0 0.0 17→18 0.37→0.47 なし L フック（2） Haiku 0.0 0.0 18→49 0.11→0.33 なし L フック（2） Opus 0.0 0.0 16→25 0.45→0.83 なし T Skill（84） Haiku 0.0 0.0 68→74 0.65→0.74 なし T Skill（84） Opus 0.0 0.0 53→58 3.13→3.76 なし V 評価（153） Haiku 5.6 2.4 71→132 0.63→1.27 あり V 評価（153） Opus 0.4 0.4 43→91 2.86→5.63 なし 対照（122） Haiku 2.7 2.0 57→91 0.48→0.81 なし 対照（122） Opus 0.0 0.0 21→36 1.92→2.30 なし ※ V の「ハーネスなし」は最初の実装（点検なし）が残した取りこぼし、「ハーネスあり」は別のエージェントが点検・修正した後の数です。ターン数とコストの「あり」は、点検のぶんが上乗せされた合計を表します。また対照の「ハーネスあり」は、あらゆる足場を盛った構成の値を指します。 そのうえで、要点を整理します。 はっきり効果が出たのは、 S（状態）と C（文脈管理）の2つだけ でした。共通するのは、 判断のその瞬間に、必要な手がかりが手元になく、資料の中身からも導けない 、という状況です。S では中断で情報がまるごと消え、C ではどちらの仕様書が正しいか分かりません。 この「情報の欠落」は能力では埋められず、外から手がかりを渡すハーネスだけが効きました 。しかも 強い Opus でも効果は変わらず、C ではむしろ Opus のほうが効果が大きい 。情報が足りないという壁は、モデルが賢くなっても越えられないようです。 反対に、 E（リトライ）・L（完了ゲート）・T（Skill）は、ほとんど差が出ませんでした 。いまのエージェントは、一時的な失敗なら言われずとも自分で走らせ直し、完了前には自分で型チェックを回し、反復の実装も難なくこなします。 手元の情報だけで完結する「閉じたタスク」では、これらのハーネスが肩代わりする仕事はもう残っていない のです。それどころか、足したぶんターン数やコストだけが増える場合もありました。 V（評価）が効いたのは、弱い Haiku のときだけ でした。Haiku は自分の実装に取りこぼしを残しがちで、そこを別エージェントの点検が拾って直します。一方で強い Opus は最初からほぼ満点のため、拾うべき取りこぼしが無く、点検は空振りに終わりました。 そして基準線（対照）でも、 あらゆるハーネスを盛った構成は、品質を上げないまま、コストとターン数だけを増やしました 。 今回の検証でいちばんはっきり見えたのは、 ハーネスは「付ければ効く」ものではなく、モデルが自力では埋められない情報の欠落を補う場合に有効 、ということでした。 Part 4. 学びを整理する 検証を通して見えてきたことを、3つの学びとして整理します。 4-1. ベストプラクティスは「そのまま従う」ものではない 今回、代表的なハーネスをひととおり試してみて、 うまく効いたものは一部だけ でした。しかも効かなかったケースでは、ハーネスを足したぶん コストやターン数だけがかさむ 、という結果すらありました。ベストプラクティスは世の中に数多く公開されていますが、 それを無条件に全部取り入れるのは、むしろ損になりかねません 。まずは最小限の構成でタスクを解かせてみて、 足りないと分かったところだけ、少しずつ足していく 。この順番が、遠回りに見えて確実だと感じました。 4-2. モデルが進化しても効くのは「知識を補う」ハーネス 効いたハーネスに共通していたのは、 モデルが知りようのない情報を、外から渡す ものでした。裏を返せば、 情報の非対称性（モデルの手元にその情報があるかどうか）が、成果を大きく左右する ということです。言い換えると、「モデルの 知能 を肩代わりする工夫」よりも、「モデルの 知識 を補う工夫」のほうが、これからも価値を持ち続けます。モデルが賢くなるほど前者の出番は減っていきますが、後者は賢さでは埋められないからです。 4-3. Haiku ですら、もう十分に賢い 正直に言うと、この検証でいちばん苦労したのは、ハーネスの実装よりも「 差がつくタスクを作ること 」でした。少し難しい課題を用意したくらいでは、 下位モデルの Haiku ですら難なく解いてしまい 、ハーネスの有無で差が出ないという状況が何度も発生しました（そもそも、Haiku という軽量モデルの存在を意識していない方も多いのではないでしょうか）。ちょっとした修正のたびに Sonnet や、まして Opus を呼んでいる人は、 一度 Haiku に任せてみる と、その賢さに驚くかもしれません。 まとめ：ハーネスは「盛る」より「効かせる」 本記事の出発点は、「ハーネスは盛れば効くのか？」という素朴な問いでした。検証を経て出た答えは、はっきり「いいえ」です。 効いたのは、 モデルが自力では埋められない情報の欠落を補うハーネスだけ でした。逆に、モデルの“知能”を肩代わりしようとする足場は、モデルが賢くなるほど出番を失っていきます。ハーネス設計の勘所は、あれもこれもと機構を盛ることではなく、 「このタスクで、モデルの手元に本当に足りていないものは何か」を見極め、そこだけを的確に埋めること にあります。 よく我々は「開発の最初期に完璧なハーネス設計をする」ということにとらわれがちですが、この結果を考えると最初にすべてを整えるのは悪手であり、むしろ最初は最低限、そこから少しずつ修正を加えていく方法がベストであるといえそうです。 これからのハーネス モデルは、これからも賢くなり続けます。その分、いま「ベストプラクティス」と呼ばれている工夫の多くは、来年には不要になっているかもしれません。実際 Anthropic 自身、あるモデル世代では必須だった機構を、次の世代では丸ごと外せたと報告しています。ハーネスとは、常に更新され、ときに“引き算”もされていくものです。 そうなると、ハーネスエンジニアリングの重心は、「モデルの不得手をどう補うか」から、 モデルが知り得ない情報・文脈・権限を、いかに的確に渡すか へと移っていくはずです。Part 2 で紹介したように、OpenAI はエンジニアの仕事の中心が「コードを書くこと」から「エージェントが信頼して働ける環境とフィードバックループを設計すること」へ移りつつある、と述べています。ハーネスを考えることは、これからますます、 AI と一緒に働く環境そのものを設計すること に近づいていくのだと思います。 ハーネスエンジニアリングは、流行り言葉として消えるどころか、モデルが進化するほど奥行きを増していく、息の長いテーマだと思います。まずは素の構成で走らせ、足りない情報だけを足してみる。その小さな一歩から、ぜひ始めてみてください。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @watanabe_shintaro レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

本記事は 2026 年 6 月 25 日から 26 日に幕張メッセで開催された AWS Summit Japan 2026 の開催報告です。AWS for Industries Zone に出展した株式会社 SUMCO のブース展示 「Amazon Redshift × 生成 AI で挑む 半導体ウェーハメーカーの DX」 の内容を、SUMCO と AWS が共同で振り返ります。 図 1: AWS Summit Japan 2026 の SUMCO ブース。実物の 300mm シリコンウェーハとともに、生成 AI を活用したデータ分析の取り組みと AWS 基盤のアーキテクチャを展示した。 SUMCO と半導体を支えるシリコンウェーハ SUMCO は半導体デバイスの基板材料となるシリコンウェーハの製造・販売を手がける企業です。社名は「Silicon United Manufacturing Corporation」に由来します。スマートフォンや自動車、データセンターに至るまで、あらゆる半導体デバイスの起点となる素材がシリコンウェーハであり、その品質は半導体の進化を根底から支えています。 シリコンウェーハは珪石から多結晶シリコンを精製し、単結晶を引き上げてインゴットとし、スライシング・ラッピング・ポリッシング・洗浄といった多数の工程を経て、鏡面ウェーハとして出荷されます。この一連の製造プロセスの各工程で、製造装置・検査装置から膨大なデータが生成されます。 図 2: SUMCO のデータ活用。各工程の検査情報・経路情報・製造装置の稼働情報を Amazon Redshift に集約し、データの意味を解釈してシリコンウェーハの状態を推定する。 背景と課題：ビッグデータを“価値”に変えるために SUMCO が目指すのは、単一工程内の改善にとどまらず、製造装置・検査装置から生じる膨大なデータ、つまりビッグデータを収集・解析することで複数工程をまたいだ改善を実現することです。前工程が後工程に与える影響を把握し、工程間の装置の組み合わせまで見据えて最適化することで、より高精度・高品質なシリコンウェーハの製造につなげます。 一方でビッグデータを実際の価値へと変えていくには乗り越えるべきテーマがありました。分析を担う人材と製造現場とでは、得意とする領域が異なります。データ分析の専門人材であるデータサイエンティストは分析手法に、製造現場は工程や品質の知見に、それぞれ強みを持ちます。この双方の強みを結びつけ、限られた専門人材だけに頼るのではなく、現場を含む組織全体でデータを活用できる状態をつくることが取り組みの出発点です。 取り組み：3 つの要素で組織のデータ活用を底上げする AWS Summit での展示は、SUMCO のデータ活用を次の 3 つの要素でご紹介しました。セキュアな基盤という土台と、その上で動く RedPulse・SynchroFabAI という 2 つのデータ活用の取り組みです。RedPulse と SynchroFabAI はいずれも SUMCO が開発した仕組みの名称です。 A. 基盤 セキュアな AWS 環境。製造データをクラウドで安全に扱うための土台 B. RedPulse 大量データの加工・比較を支えるデータ処理の仕組み C. SynchroFabAI 生成 AI で自然言語によるデータ解析を行う取り組み 図 3: データ分析基盤の全体像。SynchroFabAI（生成 AI アプリ）と RedPulse（データパイプライン＋データ処理）が、Amazon Redshift を中核とする基盤とともに構成される。 A. 基盤：製造データを安全にクラウドで活用する 製造データをクラウドで安全に活用するための土台となるのが、AWS 上に構築されたセキュアな基盤です。半導体業界はセキュリティ要件が厳しく、製造データをクラウドで扱うこと自体が挑戦的な取り組みであるため、その土台には堅牢なガバナンスが不可欠でした。 SUMCO の AWS 基盤は工場と AWS を安全につなぎ、用途ごとにアカウントを分離した構成をとっています（図 4）。この基盤はネットワーク統制と権限統制の 2 つの観点で運用されています。 ネットワーク統制（閉域網の構築） AWS 環境からインターネットへの直接通信を禁止 AWS Direct Connect を用いたオンプレミスと AWS 間の専用ネットワーク接続 権限統制 AWS Identity and Access Management (IAM) による必要最小限の権限付与 AWS Organizations のサービスコントロールポリシー (SCP) による組織全体への予防的統制 AWS 環境に対して社内 IP アドレス以外からのアクセスを制限 図 4: AWS 基盤の全体構成。Organization・User・DWH のアカウントを分離し、AWS Transit Gateway で接続。工場からは AWS Direct Connect 経由で取り込み、DWH アカウントの Amazon S3・Amazon Redshift にデータを集約する。 運用から、社内向けシステムの企画・ソリューション提供へ SUMCO 社内の AWS チームの役割は基盤の運用にとどまりません。IAM の最小権限設計や AWS サービスの払い出し、社内向けの AWS サポート・教育を担いながら、さらに AWS の技術を使った社内向けシステムの企画から、現場へのソリューション提供までへと取り組みを広げています。この社内 AWS チームの活動が、次に紹介する 2 つのデータ活用の取り組みを支えています。 図 5: SUMCO 社内 AWS チームの取り組み。基盤構築・運用・教育を土台に、社内向けシステムの企画とソリューション提供へと役割を広げている。 B. RedPulse：データ加工の知見を組織で共有する RedPulse は大量データの加工・比較を支えるデータパイプラインとデータ処理の仕組みです。製造装置が生成する製造中の時系列データを抽出し、複数の装置や時間帯といった条件で比較できます。これまで熟練者の経験に根ざしていたデータ加工の手順を仕組み化し、誰もが同じ手順で大量データを扱えるようにすることで、分析の入口となる作業を組織の共有資産にします。 図 6: RedPulse。製造中の時系列データを抽出し、複数の装置・時間の条件で比較できる。 実装面では、工場から取り込んだデータを Amazon Simple Storage Service (Amazon S3) に CSV / Parquet 形式で格納します。その後 AWS Lambda や Amazon Elastic Container Service (Amazon ECS) でデータパイプラインを通じた処理を実行し、 Amazon Redshift を中核とするデータ分析基盤に集約しています。 図 7: RedPulse のアーキテクチャ。工場のデータを Amazon S3 に格納し、AWS Lambda・Amazon ECS でデータパイプラインとデータ処理を行い、Amazon Redshift に集約する。 RedPulse で取得・整形した時系列データは、機械学習による品質予測や、品質に強く寄与するパラメータの要因分析へとつながります。RedPulse は、こうしたデータ分析業務を支える役割を担っています。 C. SynchroFabAI：生成 AI で意味づけ・分析の知見を組織で共有する SynchroFabAI は生成 AI を活用して自然言語でビッグデータを解析する取り組みで、本記事執筆時点では PoC 段階です。データの意味を説明し、分析手法を提案・実行することで、分析の専門人材でなくても自然言語での対話だけでデータ分析を進められることを目指しています。 図 8: SynchroFabAI。自然言語での問いかけに対し、AI がデータの意味を説明し、分析手法を提案・実行する。 実装面では、オンプレミス環境に配置した AI エージェントの Cline が Amazon ECS 上に構築した Model Context Protocol (MCP) サーバーを介して、AWS 上の Amazon Redshift のデータソースを参照します。Cline の推論においては、 Amazon Bedrock で大規模言語モデルを利用します。Cline の振る舞いは Rules や Skills、および分析手法を記述した参照ファイルによって制御しています。 図 9: SynchroFabAI の実装。オンプレミスの Cline から、MCP を介して AWS 上の Amazon Bedrock・Amazon Redshift を利用する。 SynchroFabAI では、AI に持たせる知識の設計、すなわち製造現場の知見のうち何を、どのような形式で AI に渡すかの見極めを工夫しています。大量データへのクエリ生成を助ける専門用語集や、データと製品状態を紐づけるためのカタログ情報を AI に与え、「異常状態の推測」や「因果関係の推測」といった役割を担わせます。本 PoC では、データ・意味づけ・分析での解釈・AI の振る舞いという各層について、AI にどこまでの役割を担わせられるか、そしてデータと製品状態の紐づけや分析手法の選択・結果解釈の妥当性を検証しています（図 10）。こうして確立した意味づけ・分析の知見を仕組みに蓄積し、組織全体で共有・再利用していくことを目指しています。 図 10: SynchroFabAI へのデータ分析フローの実装。データ・意味づけ・分析での解釈・AI の振る舞いの各層について、AI に担わせる役割と、PoC で検証している内容を対応づけている。 “RedPulse では、Amazon Redshift の処理性能を引き出すことを念頭に SQL を作成・チューニングすることで、これまで時間を要していた大量データの集計が現実的な時間で回るようになり、Amazon Redshift のパワーを強く実感しました。SynchroFabAI では、生成 AI がデータの意味づけまで踏み込んで担う点が新鮮であり、集計や可視化の先にある「解釈」の領域にまで仕組みを広げられることは、現場のデータ活用の裾野を大きく広げると感じています。加えて、SynchroFabAI の設計にあたっては、専門用語集やカタログ情報として生成 AI に渡す知識の設計、そして意味づけ・分析手法の提案までを AI に担わせ、結果の妥当性の確認は人が担うという役割分担を、データサイエンティストと議論を重ねながら形にしていきました。実装側の視点だけでは辿り着けない分析の観点や知識に触れられたこの設計の過程こそ、本取り組みならではの面白さだったと感じています。” ― 株式会社 SUMCO AI推進本部 ICT推進部 荒木 亮 氏 今後の展望：データ活用を一部の専門人材から組織全体の力へ SUMCO の取り組みは単なる分析ツールの導入にとどまりません。多品種生産という SUMCO の事業価値を支えるには、品種・工程に合わせた分析やアプリケーションが必要になります。データ加工の知見である RedPulse と、意味づけ・分析の知見である SynchroFabAI を組織の共有資産としていくことで、限られた専門人材への依存を減らし、現場を含む組織全体のデータ活用の底上げを図ります。 セキュアな AWS 環境という土台の上に、データ基盤の確立、そして生成 AI の活用へと、SUMCO は着実に歩みを進めてきました。この積み重ねの先に、現場を含む組織全体でデータを活かせる状態の実現を見据えています。 “データは当社の競争力の源泉であり、それを一部の専門人材だけでなく組織全体で活用できるようにすることは、多品種生産を強みとする当社にとって不可欠な変革です。今回の取り組みは、その第一歩として大きな手応えを感じています。セキュアな基盤の上で現場と分析をつなぎ、変化に素早く対応できる組織へ。AWS とともに、この歩みをさらに加速させていきます。” ― 株式会社 SUMCO AI推進本部 ICT推進部 部長 武富 太志 氏 おわりに AWS Summit Japan 2026 の SUMCO ブースでは、実物のシリコンウェーハとともにデータ活用の取り組みを紹介しました。厳しいセキュリティ要件のもとで製造データをクラウドと生成 AI で活用する SUMCO の挑戦は、同じ課題に向き合う製造業の皆さまにとって、参考となる点があるのではないかと考えています。 SUMCO と AWS は、これからもデータ活用 DX の歩みをともに進めてまいります。本記事が、製造業におけるデータと生成 AI の活用を検討されている皆さまの一助となれば幸いです。 図 11: AWS Summit Japan 2026 の SUMCO ブースにて。展示を支えた SUMCO の皆さまと、AWS メンバー。 執筆者について 武富 太志 株式会社SUMCO AI推進本部 ICT推進部 / 部長 「データを、現場の力に変える」をテーマに、工場で生まれる膨大なデータをAIやクラウドで活用し、ものづくりの現場をスマートにする取り組みを率いる。難しいIT技術を社員が使いこなせるよう教育にも力を注ぎ、「一部の専門家だけでなく、全員でデータを使いこなせる会社」を目指して日々奮闘中。 荒木 亮 株式会社SUMCO AI推進本部 ICT推進部 半導体業界において、製造装置の制御技術と工場のデータ基盤、双方の実務領域にエンジニアとして関わってきた。SUMCOでは製造現場の知見をシステムとして具現化することで、ITを軸とした自動化とデータ活用に取り組んでいる。社内ではいつの間にか「万屋（よろずや）」と呼ばれるようになり、静かに受け入れつつも、熱量に限ってはその肩書きが窮屈らしい。 大森 敬太 株式会社SUMCO ウェーハ技術部 プロセス企画課 / データサイエンティスト 2021年にSUMCOへ入社後、ICT部門に配属。SEとしてIT知識を習得しながら、製造現場の見える化推進に取り組む。その後、システム開発やデータ分析業務など幅広いICT関連業務を経験。2023年よりデータサイエンス課に配属。現在、データサイエンス分野の博士後期課程に社会人博士として在学中。製造現場とデータ分析をつなぐ役割を担い、組織全体のデータ活用推進に取り組んでいる。 酒井 賢 アマゾン ウェブ サービス ジャパン合同会社 ハイテク＆ヘルスケア・ライフサイエンス部 / シニアソリューションアーキテクト IT 業界で 20 年以上の実務経験を持つソリューションアーキテクト。2020 年の AWS 入社後、製造業を中心にさまざまな業種の企業を支援し、現在は半導体業界を専門としている。企業がクラウドソリューションを計画・実装し、AWS 上で安全かつ高性能で柔軟な費用対効果の高い環境を構築することへの支援に注力している。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 いよいよ AWS Summit Japan 2026 が 6 月 25 日（木）、26 日（金）に幕張メッセで開催されます。今週は各業界ブースの見どころを紹介するブログが続々と公開されました。AI Scientist が実験用ロボットを自律操作する創薬向けの  Self-Driving Lab 、AI エージェントが生産ラインのボトルネックを検知して改善する 製造業向けデモ 、ユナイテッドアローズ様・カインズ様の事例展示を含む 流通・小売・消費財・飲食業界向けブース など、生成 AI エージェントが業務の主役になる未来を体感できる展示が目白押しです。ぜひ事前にチェックしてみてください。 それでは、6 月 8 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース AWS Local Executive Roadshow 名古屋編: タキヒヨー株式会社様、非エンジニアが数週間で社内システムを内製化 タキヒヨー株式会社様は、1751 年創業、270 年以上の歴史を持つ繊維・アパレル企業です。経営に必要なデータが Excel に散在し、VBA マクロでの集計に追われていたことや、需要予測データが分析できる形になっていないことが課題でした。これを解決するために、まず Amazon QuickSight でデータを一元的に可視化し、さらに非エンジニアの担当者が Amazon Bedrock 経由の Claude Code を使ってデータ整形ツールを内製開発しました。その結果、通常なら数カ月・数百万円かかるシステムを数週間で構築し、現場が意思決定業務に集中できるようになったそうです。パートナーのクラスメソッド株式会社様とともに、「まずは可視化から始める」という現実的なアプローチが語られている開催レポートです。 AWS Local Executive Roadshow 広島編: 株式会社エイチビーソフトスタジオ様、生成 AI 導入の「3 つの壁」を乗り越える 株式会社エイチビーソフトスタジオ様は、愛媛県松山市を拠点に全社員リモートで開発を手がける企業で、中小企業への生成 AI 導入支援にも取り組んでいます。支援先では、問い合わせ対応が特定の担当者に集中し回答品質にばらつきが出ることや、導入時の「期待値の壁」「ルール（ガバナンス）の壁」「データの壁」が課題でした。これを解決するために、Amazon Bedrock を活用しつつ、ハンズオンによる期待値調整、叩き台ベースでの運用ルール作り、AI に社員へインタビューさせて属人ノウハウをドキュメント化する、といった工夫を重ねました。その結果、対応時間の削減や負荷集中の緩和に加え、「完璧を待たず小さく始める」ドキュメント化の文化が根づいたそうです。 AWS Summit Japan 2026 流通・小売・消費財・飲食業界向けブースのご案内 テーマは「AI エージェントが業務の主役になる日」。「商品をつくる・届ける・売る / つながる」の 3 つの切り口で、バーチャル AI エキスパートやマルチエージェントによる製品開発、サプライチェーンの危機対応など 6 つのデモを体験できます。あわせて、株式会社ユナイテッドアローズ様の「Amazon Bedrock で実現 対話で深まる日報 AI」や、株式会社カインズ様の「AI で進化する顧客体験」といったお客様の事例展示も予定されています。 AWS Summit Japan 2026 製造業ブース「生産ラインの未来」のご案内 AI エージェントが生産ラインのボトルネックを検知し、改善までを一気通貫で支援するデモを紹介しています。需要の増加を検知して影響を分析し、ボトルネックの特定から工程設計書を参照した改善提案、PLC プログラムの改修案づくり、シミュレーション環境での事前検証までを、エージェントとの会話で体験できます。Amazon Neptune や AWS IoT SiteWise、Amazon Bedrock AgentCore などを活用した構成です。 フィジカル AI で創薬が変わる Self-Driving Lab のご紹介（ヘルスケア・ライフサイエンスブース） AWS 上の AI Scientist が実験用ロボットを直接操作し、設計・実行・分析（DMTA サイクル）を 24 時間自律的に回す「Self-Driving Lab」のデモを紹介しています。会場では、3 色の原液の配合比率を AI が自律的に突き止める実演が行われます。アッセイ条件の最適化や製剤処方の設計などにも応用でき、創薬研究の加速が期待できる内容です。 ブログ記事「 AWS、初の一般提供版 Mythos クラスモデルとなる Claude Fable 5 を発表 」を公開 Anthropic の最上位クラス「Mythos」レベルの機能を、強力なセーフガードを組み込んだうえで一般提供する Claude Fable 5 が発表されました。長時間の非同期実行や高度なビジョン機能、成果物を提供する前に自ら結果を検証する能力が特徴で、評価されたほぼすべてのベンチマークで最先端の性能を示すモデルです。Amazon Bedrock と Claude Platform on AWS の 2 つの方法でアクセスできます。なお本記事には 6 月 12 日付の更新があり、米国政府の輸出管理指令への準拠のため、Anthropic の要請により現在 Claude Fable 5 および Claude Mythos 5 へのアクセスは停止されています（Claude Opus 4.8 などの他モデルは影響を受けません）。ご利用前に最新の提供状況をご確認ください。 ブログ記事「 AWS FinOps Agent のパブリックプレビュー提供開始のお知らせ 」を公開 コスト管理を継続的な運用へと進化させるエージェント型 AI ソリューション AWS FinOps Agent がパブリックプレビューになりました。この記事では、コスト異常を AWS CloudTrail のイベントと関連付けて根本原因と責任者を特定し、Jira チケットや Slack に調査結果を届ける仕組みや、エンジニアが「なぜ先月コストが上がったのか」を自然言語で質問できる機能を紹介しています。Workday 様や Mitre 10 様など初期のお客様の声も掲載されています。月次レビューに追われている FinOps チームの方は必見です。 ブログ記事「 AWS DevOps Agent によるネットワークインシデント対応の自動化 」を公開 この記事では、Amazon CloudWatch のアラートを Webhook で受け取った AWS DevOps Agent が、メトリクス・ログ・ネットワークフロー・API 変更履歴を相関分析し、根本原因と修復プランを提示する方法を紹介しています。セキュリティグループの設定ミスや NAT Gateway のルート削除など、すぐに試せる 4 つのシナリオと、複数アカウントにまたがる Transit Gateway の事例を CloudFormation テンプレート付きで解説しています。手動で 1 時間かかっていた切り分けを数分に短縮できる様子は一読の価値ありです。 ブログ記事「 Amazon Bedrock AgentCore でマルチテナントエージェントを構築する 」を公開 SaaS プロバイダーがエージェント型アプリケーションを本番運用するには、テナント分離やコスト配分、セキュリティといった固有の課題に向き合う必要があります。本記事はシリーズ第 1 回として、Amazon Bedrock AgentCore を使ったサイロ・プール・ブリッジの 3 つの分離パターンと、ランタイム分離・トークン伝播・メモリ階層・ガードレールなど 10 個の設計コンポーネントを体系的に整理しています。マルチテナント SaaS でエージェントを設計する際の見取り図として参考にして頂けるのではないでしょうか。 ブログ記事「 Anthropic / OpenAI 互換 API 向けに最適化された Amazon Bedrock の新しいコンソールエクスペリエンス 」を公開 この記事では、最新の GPT・Claude・オープンウェイトモデルに対応する Amazon Bedrock の次世代推論基盤と、その新しいコンソール体験を紹介しています。最大 3 モデルを比較できるモデルカード、プロジェクト単位での作業、プロジェクト変数を自動で埋め込むライブドキュメントなどにより、モデルの発見から本番移行までをスムーズに行えます。Claude Code や Cline、Cursor などの AI コーディングエージェントとの接続手順も紹介されています。 ブログ記事「 キャパシティ対応推論: SageMaker AI エンドポイントにおけるインスタンスの自動フォールバック 」を公開 GPU キャパシティ不足でエンドポイントの作成や Auto Scaling が失敗する、という悩みを解消する Amazon SageMaker AI の新機能「キャパシティ対応インスタンスプール」を紹介する記事です。優先順位を付けたインスタンスタイプのリストを定義しておくと、キャパシティ制約時に SageMaker AI が自動でリストを順に試し、利用可能なインフラ上にプロビジョニングしてくれます。生成 AI モデルの推論基盤を安定運用したい方におすすめの内容です。 ブログ記事「 2026 AWS Life Sciences Symposium ハイライト: 創薬研究領域 」を公開 この記事では、Sanofi 様や Roche 様、ブリストル マイヤーズ スクイブ様といったリーダーが登壇した本シンポジウムから、エージェント型 AI の創薬活用の最前線を紹介しています。目玉は 40 以上の生物学基盤モデルを備えた Amazon Bio Discovery のローンチで、メモリアル・スローン・ケタリングがん研究所の事例では、標的に対してわずか数週間で高い親和性を持つナノボディを設計した様子が語られています。エージェント型 AI が「将来の約束」ではなく本番インフラとして使われ始めていることが分かる内容です。 ブログ記事「 Kiro の Spec が速く、そしてスマートになりました 」を公開 AI を活用した IDE である Kiro の仕様駆動開発（Spec）フローに、3 つの新機能が追加されました。独立したタスクを依存関係に基づいて同時に処理する「並列タスク実行」、要件・設計・タスクを一度に生成する「Quick Plan」、そしてニューロシンボリック AI で要件の曖昧さや矛盾を設計前に検出する「要件分析」です。「構造と品質を求めると遅くなる」という前提を覆す内容で、大きな Spec の実装時間が大幅に短縮されるとのことです。 ブログ記事「 生成 AI で開発ツール操作を自動化 – Kiro × MCP Server × dSPACE ControlDesk 」を公開 自動車の ECU 開発で使われる dSPACE ControlDesk の複雑な GUI / API 操作を、AWS 上に構築した MCP サーバーと Agentic IDE「Kiro」の組み合わせで自然言語から自動化するアプローチを紹介する記事です。Amazon EC2 上の MCP サーバーが API マニュアルやサンプルコードをナレッジとして保持し、Kiro が ControlDesk を操作する Python コードを自動生成します。API 仕様を調べる時間や新メンバーのオンボーディングコストの削減に役立つ、実践的なユースケースとして参考になります。 サービスアップデート AWS、初の一般提供版 Mythos クラスモデルとなる Claude Fable 5 を発表 Anthropic の Mythos レベルの機能を一般提供する Claude Fable 5 が AWS で発表されました。金融・法務・マーケティング・エンジニアリングなどの専門業務向けに設計され、学習結果に基づいてスキルを自律的に更新し、自ら評価ハーネスを開発して成果物を検証します。Amazon Bedrock と Claude Platform on AWS の 2 つの経路でアクセスできます。なお前述のとおり、6 月 12 日以降は輸出管理指令への準拠のためアクセスが停止されているため、ご利用前に最新の提供状況をご確認ください。 Google DeepMind の Gemma 4 モデルが Amazon Bedrock で利用可能に Google DeepMind のオープンウェイトモデル Gemma 4 ファミリーが Amazon Bedrock で利用可能になりました。Gemma 4 31B、26B-A4B、E2B の 3 種類があり、組み込みの推論機能、ネイティブな Function Calling、35 以上の言語、テキスト・画像・動画・音声のマルチモーダル入力に対応します。31B は最大 256K トークンのコンテキストウィンドウを備え、推論やコーディング中心のワークロードに適しています。現在、米国東部（バージニア北部）、米国東部（オハイオ）、米国西部（オレゴン）、欧州（フランクフルト）で利用可能です。 OpenAI の GPT-5.4 / GPT-5.5 が Amazon Bedrock の米国東部（バージニア北部）で利用可能に OpenAI の GPT-5.4 と GPT-5.5 が、Amazon Bedrock の米国東部（バージニア北部）リージョンでも利用可能になりました。GPT-5.5 は OpenAI の最も高性能なモデルで、高度なコーディングや調査・分析、長時間にわたるエージェント型タスクに向いています。両モデルとも 272K トークンのコンテキストウィンドウとテキスト・画像入力に対応し、Responses API を通じてサーバーサイド・クライアントサイド両方のツール呼び出しやレスポンスストリーミングを利用できます。 Amazon SageMaker AI が NVIDIA Nemotron モデルのサーバーレスファインチューニングに対応 Amazon SageMaker AI が、NVIDIA の 30B オープンウェイトモデル Nemotron 3 Nano のサーバーレスなモデルカスタマイズに対応しました。教師ありファインチューニング（SFT）と強化学習ファインチューニング（RFT）が利用でき、独自データでドメインに合わせた調整が行えます。サーバーレスのため、インフラのプロビジョニングや学習のオーケストレーションは SageMaker AI が処理し、使った分だけの課金でクラスター管理から解放されます。アジアパシフィック（東京）を含む 4 リージョンで利用可能です。 Amazon OpenSearch Serverless が Agentic Search をサポート Amazon OpenSearch Serverless で、自然言語でデータをクエリできる Agentic Search 機能が利用可能になりました。「800 ドル未満で東京行きのフライトを検索する」のように尋ねるだけで、システムが意図を解釈し、最適な検索戦略を計画して適切な DSL クエリを生成し、推論内容の説明とともに結果を返します。背後では LLM を搭載した QueryPlanningTool が自然言語を DSL クエリに変換します。OpenSearch Serverless が提供されているすべての商用リージョンで利用できます。 Amazon OpenSearch Service が エージェント型オブザーバビリティ向けの MCP Apps を提供開始 Amazon OpenSearch Service が MCP Apps に対応し、Claude Desktop や VS Code といった agentic IDE の中で直接オブザーバビリティのワークフローを実行できるようになりました。ローカル環境の AI エージェントが、OpenSearch や Amazon Managed Service for Prometheus に保存されたログ・トレース・メトリクス・アラートを使ってインシデントを調査できます。各ツール呼び出しはエージェント向けの要約テキストと、会話内に描画されるインタラクティブな可視化の両方を返すため、環境を離れずに結果を確認できます。 AWS で AI を活用したコスト調査機能が提供開始 AWS Cost Anomaly Detection に、Amazon Q を使って検出されたコスト異常の根本原因を分析する機能が搭載されました。これまで数時間かかることもあったコスト変化の調査が、わかりやすい言葉での説明として数分で得られます。Amazon Q がコスト変化を使用量主導型かレート主導型かを判断し、原因となったサービス・アカウント・リージョンを特定。使用量主導型の変更は AWS CloudTrail と関連付けて、特定の API コールや IAM プリンシパルに帰属させます。すべての商用リージョンで追加料金なしで利用できます。 AWS Cost Explorer で Amazon Q を活用したインテリジェントなコスト説明機能を提供開始 AWS Cost Explorer に「Amazon Q を利用して分析」機能が追加されました。ボタンを 1 回クリックするだけで、設定したレポートに対するコスト傾向・主なコスト要因・異常などの詳細な分析を受け取れます。設定したフィルターと期間はそのまま分析に引き継がれ、過去の日付には履歴の説明、将来の日付には予測の説明が提供されます。会話を通じてコンテキストが維持されるため、フォローアップの質問で深掘りも可能です。すべての商用リージョンで追加料金なしで利用できます。 Amazon Quick が Snowflake Cortex AI との統合に対応 Amazon Quick が、Model Context Protocol（MCP）を通じて Snowflake Cortex AI と統合できるようになりました。Snowflake のマネージド MCP サーバーを OAuth 認証で接続すると、Cortex Analyst を通じた構造化データへの問い合わせや、Cortex Search を通じた非構造化文書からのインサイト取得を、自然言語で実行できます。Quick の Flows で Snowflake Cortex Agents をオーケストレーションし、繰り返し可能でガバナンスの効いたワークフローを構築することも可能です。Amazon Quick が利用可能なすべての AWS リージョンで利用できます。 Kiro のアップデート Kiro CLI 2.7 が公開、/goal ループと Queue Steering を追加 AI を活用した IDE である Kiro のコマンドラインツール Kiro CLI 2.7 が公開されました。目標を達成するまで実装と自己検証を繰り返す /goal ループ、実行中のエージェントにツール境界で指示を割り込ませる Queue Steering、各ターンのツール呼び出しや変更ファイルを一覧できる強化版 /rewind が追加され、エージェントの自律性ときめ細かな制御をより両立しやすくなりました。 Kiro Web が GitLab 連携とブラウザ上での Spec 実行に対応 ブラウザで動作する Kiro Web に、2 つの機能が追加されました。要件・設計・タスクからなる Spec ワークフローをブラウザ上で実行できるようになり、GitHub に加えて GitLab にも対応しています。1 つのセッションで GitLab と GitHub のリポジトリを混在して扱い、それぞれにマージリクエストやプルリクエストを作成できるようになりました。 Kiro の新プラン「Kiro Pro Max」（月額 100 ドル）が登場 Kiro に、Pro+（月額 40 ドル）と Power（月額 200 ドル）の間を埋める新プラン Kiro Pro Max（月額 100 ドル）が追加されました。月 5,000 クレジット（Pro+ の 2.5 倍）とすべてのプレミアムモデル、Specs・カスタムサブエージェント・powers・hooks といったフル機能を利用でき、Kiro を日常的に使う開発者向けの予測可能な定額プランとなっています。 生成 AI を活用したビジネス変革に取り組むお客様を支援する 生成 AI 実用化推進プログラム は引き続き参加企業を募集しています。ご興味のある方はぜひご覧ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。