Claude 5世代のモデル向けにコンテキストエンジニアリングの考え方が変わっているよという公式記事。↓は自分用メモ。 ・Claude Codeのシステムプロンプトを80%以上削減しても、コーディングの精度は維持している ・以前は事故を防ぐため「コメントを書くな」等の強い制約を設けていた ・ただ、それがかえって指示の衝突を生み、AIの判断を難しくさせる原因になっていた ・最新モデルは判断力が向上しているため、細かいルールよりAIの裁量に任せた方が良い ・ツールの具体的な使用例を提示すると、逆にAIの探索範囲を狭める ・例を見せるよりも、パラメーター設計などを工夫して意図を伝える方が良い ・ツールの使い方はシステムプロンプトではなく、各ツールの説明文に記載する ・すべてのベストプラクティスをCLAUDE.mdに詰め込むのは良くない ・必要な時に情報を読み込ませるprogressive disclosure（段階的に開示）が良い ・長いドキュメントは分割し、適切なタイミングで参照させる ・CLAUDE.mdは軽量に保つ ・コードベース特有の注意点の記載にとどめる ・また、単純なMarkdownの仕様書より、もっと情報量を増やしていい。例えば、HTMLのモックアップやテストコードを渡す方が精度が上がる

AIでCOBOLからJavaへコード移植する方法の提案論文。 ・レガシーなCOBOLからJavaへの移行は、テストデータ不足で隅々まで検証するのが難しい ・そこで Locksmith Loop と呼ばれるAIエージェントによるテスト生成手法を提案 ・COBOLと生成されたJavaの双方にモックを組み込んで実行環境を用意 ・エージェントが入力値の探索と変異を反復し、プログラムの条件分岐の奥深くまで入り込む ・探索がブロックされた条件を特定して突破することで、カバレッジを広げていく ・今回は、430〜4,114行規模の3つのCOBOLプログラムでケーススタディを実施した ・結果として、オープンソースのプログラム2つではほぼ完全な網羅率に到達 ・実稼働相当の内製プログラムでも91.90%の分岐カバレッジを達成した

AIの信頼性は「自己反省」では足りない。答える前に別のエージェントが“監査”する時代へ🔬 タイトル: Apodex-1.0: A Verification-Centric Agent Team for Discoverative Intelligence URL: 🔬 概要 単一エージェントの推論ループから、検証を重視する分散エージェントチームへと転換したシステムです。ヘビーデューティモードでは、専門化・相互チェック・自己監査を行う非同期チームとして難問に挑みます。 ❓ 解決する課題 難しくオープンエンドな問題での信頼性は、モデルの学習済み知識だけでは得られません。最も難しい研究課題は、モデルの能力ではなく「モデルが何と相互作用できるか」に制約されている、という問題意識が出発点です。 💡 方法論と提案手法 ・メインエージェントが、独立した文脈とツールを持つ専門サブエージェントを非同期に起動 ・共有レポートプールで並列探索の結果を集約（遅いタスクを待たない） ・検証エージェントチームが矛盾解消・ファクトチェック・草稿レビューを担当 ・核心は「外部監査としての検証」。推論役と監査役を分離し、検証器は異議を唱える自由を持ちます ・単一タスクで最大150サブエージェント・15,000ステップ超を非同期協調 📊 実験結果 ・BrowseComp 90.3 / DeepSearchQA 94.4 / BrowseComp-ZH 84.1 ・FrontierScience-Research 46.7（競合+8）/ SuperChem 74.2（次点+12） ・ヘビーモードはベースをBrowseCompで+14.8、研究で+18.4押し上げ ・オープン版4B-SFTが30B級のOSSモデルを上回る #AIエージェント# #DeepResearch#

# AIエージェントをエンタープライズシステムに組み込む意思決定ポイント # 自律 vs 決定論ワークフロー｜Autonomous vs Deterministic Workflow 🎯 ポイント エージェントに「自由に考えて動いて」と任せますか、それとも「この手順通りに実行して」と指示しますか？ 自律は柔軟だが予測不能、決定論は硬直だが監査可能。この分岐を副作用の可逆性と影響度で判断せず「なんとなく自律」で設計すると、不可逆な操作をエージェントの自律判断に委ねて取り返しのつかない事態を招きます🔑 📋 概要 自律型はエージェントが自由にステップを計画・実行するアプローチです。タスクのバリエーションが多く、事前にすべてのフローを定義するのが非現実的な場面で力を発揮します。情報検索・要約・分析など読み取り専用の操作が中心で、誤りがあっても容易に取り消し可能な場合に適しています。決定論ワークフローは事前定義されたフローに従わせるアプローチで、操作の副作用が不可逆または高影響（決済処理、契約変更、本番デプロイ、人事異動）な場合、そしてSOX / GDPR / 金融規制により監査証跡が必須な場合に選びます📊 🔍 意思決定のポイント 判断は副作用の有無と可逆性で行います： 副作用なし（読み取り専用）→ 自律で問題なし 副作用あり＋可逆 → 自律＋事後検証で対応可能 副作用あり＋不可逆 → 決定論＋事前承認が必須 規制要件あり → 決定論で監査証跡を確保 タスクの多様性も重要な判断材料です。パターンが固定的なら決定論で最適化し、多様で予測不能なら自律で柔軟に対応します。ただし自律でも、高リスク操作の前にHITL（Human-in-the-Loop）承認ゲートを挿入すれば安全性を確保できます⚡ 💡 要点と詳細 本番環境では純粋な自律も純粋な決定論も少なく、ハイブリッドが主流です： 自律で計画、決定論で実行：エージェントが自律的にタスクを分解・計画し、各ステップの実行は事前定義されたワークフロー（API呼び出しの順序・バリデーション・承認ゲート）に従います。計画の柔軟性と実行の安全性を両立する最も実用的なパターンです。 リスクレベルによる切り替え：読み取り操作は自律、書き込み操作は決定論ワークフローに自動ルーティング。二重トラック検証と組み合わせるのが定石です。 ServiceNowのインシデント対応を例にすると、原因調査は自律（ログ検索・仮説生成・検証を柔軟に実行）、復旧操作は決定論（定義済みのランブック手順に従う）という使い分けが理にかなっています。 監査証跡は全モードで記録してください。自律モードでも「なぜその操作をしたか」を追跡できる操作ログが不可欠です🔄 ⚖️ トレードオフ 不可逆な操作を自律に任せるリスクは計り知れません。Shopifyで数千商品の価格を一括変更する操作をエージェントの自律判断に委ねた結果、誤った価格設定で損害が発生するケースは現実に起こり得ます😰 一方、すべてを決定論にすると、情報検索や要約まで固定フローに閉じ込め、エージェントの柔軟性を完全に殺してしまいます。「AIエージェント」である意味がなくなり、従来のルールエンジンと何も変わりません。 ハイブリッドの境界が曖昧なのも危険です。自律と決定論の切り替え条件が明文化されていないと、開発者によって実装がバラつきます。操作のリスク分類を先に定義し、切り替え条件をコードで明文化しましょう⚠️ 🛠️ ユースケース ナレッジ検索＋ドキュメント編集：Notion / Confluenceでのナレッジ検索と情報要約は自律モード（読み取り専用、柔軟な探索が価値を生む）。ドキュメントの本番公開や共有範囲変更は決定論ワークフロー（承認ゲート＋監査ログ）📚 EC運営（Shopify）：商品情報の検索・分析は自律。在庫調整は決定論（変更量のバリデーション＋承認）。一括価格変更は決定論＋ドライラン必須（差分プレビュー→人間確認→実行）。同じエージェントでもリスクレベルで実行モデルを切り替えます🛒 インシデント対応（ServiceNow）：原因調査フェーズは自律（ログ検索→仮説立て→検証を柔軟に）。復旧フェーズは決定論（ランブック手順通り、各ステップに承認ゲート）。調査は自由に、実行は厳密に🔧 実践のコツ：「自律と決定論の境界」をリスク分類表として先に定義してください。各操作を「読み取り」「可逆書き込み」「不可逆書き込み」「金銭移動」に分類し、それぞれの実行モデルを決めておくのが安全な運用の出発点です💪 #AIエージェント# #エンタープライズアーキテクチャ#

AIエージェントの「記憶」機能、過去の作業履歴だけを見て学習させると、間違った知識を覚え込んでしまうことがあります。それを防ぐ賢い工夫を紹介します。 タイトル: Grounding Agent Memory: Environment-Probing Curation for Enterprise Agents URL: ❓ 従来のエージェント記憶の何が問題だったの? 💡 完了した作業履歴だけを見て記憶を作ると、1回のたまたまの観察から間違った一般化をしたり、データベースのスキーマが変わった途端に記憶が使えなくなったりしていました。 ❓ この論文はどう解決するの? 💡 記憶を保存する前に、エージェントに読み取り専用で実際の環境を「プロービング（探査）」させ、保存しようとしている知識が本当に正しいかを検証してからコミットする仕組みを提案しています。 ❓ 効果はどれくらいあるの? 💡 データベース探索タスクでは合格率が39%から73%に向上し、報酬は約2.6倍に。しかもツール呼び出し回数は47%減、コストも約50%削減できています。 ❓ 実運用でも使えそう? 💡 モデルの再学習が不要で、タスク実行時のインターフェースも変えずに導入できるため、企業で長期運用するエージェントにそのまま組み込みやすい設計になっています。 #AIエージェント# #エージェントメモリ#

AIエージェントの性能はモデルだけで決まらない——ハーネスの設計次第で大きく変わります。 TL;DR JIT-Agentはタスクの特性に応じてエージェントハーネス（スキャフォールド）をジャストインタイムで自動生成・修復・進化させる専用モデルです。GLM-5.2で+7.7pt、DeepSeek-V4-Flashで+8.8ptの平均向上を達成し、9ベンチマーク中8つでGPT-5.6を含む全フロンティアモデルを上回りました。 タイトル: Scaling Harness Intelligence via Just-in-Time Harness Evolution URL: ポイント 🧩 ハーネスを「学習可能なアーティファクト」として定式化 メモリ・計画・アクション・能力オーケストレーションの4モジュールプロトコル h = (M, P, A, F) でハーネスを形式化。生成空間を制約しつつ13種類の既存ハーネスを全て表現できる設計です。 🎓 教師あり→修復→進化の3段階訓練 ステージIで教師生成ハーネスを学習、ステージIIで実行失敗時の修復を学習（最大2反復）、ステージIIIのEvo-GDPOでパレートフロンティアを前進させる新規ハーネスを進化的に探索します。 📊 精度向上とコスト削減を同時達成 xBench-DeepSearchでスコア78→82（+4pt）の一方、トークン消費は527K→212K（▲60%）、コストは$0.075→$0.039（▲48%）。9ベンチマーク平均で固定ハーネス比36%のトークン削減を実現しています。 ⚡ 複数モデルファミリーに転移可能 JIT生成ハーネスはDeepSeek V4（+10.2pt平均）、Mimo V2.5（+8.6pt）、Qwen 3.6（+4.0pt）でいずれもReActを上回り、ハーネス生成器を再訓練せずに転移できます。 🔄 ストリーミングモードで運用中も進化 デプロイ後もタスクシーケンスをまたいでハーネスを蓄積・更新する「オンライン進化」を実装。静的生成より全評価ベンチマークで上回ります。 ベースモデルのスケーリングと独立した「ハーネス知性」という新たなスケーリング軸の提案として注目です。 #AIエージェント# #LLMスケーリング#

AIエージェントをエンタープライズシステムに組み込むプラクティス 【信頼度ゲート棄権・エスカレーション】 💡 最も危険なAIは「分からないのに答えるAI」です。「答えない」を正常な出力として設計することが、エンタープライズ品質への第一歩です。 🔥 解決する課題 - 分からないことを分からないと言えず、ハルシネーションで誤情報を提供する - エージェントが根拠のない確信で不正確な回答をする（過信） - 専門知識が必要な質問に不適切な自動回答を返してしまう - 有人対応すべき案件がエージェントで完結し、顧客満足度が低下する 🏗️ 提案パターン 自己評価・検索ヒット品質・検証器合否・不確実性シグナルの複合でスコアリングし、閾値未満なら「分かりません」と回答して人間へ転送（warm handoff）します。転送時はそれまでの会話文脈を引き継ぎ、人間がゼロから対応する必要をなくします。封じ込め率（エージェントが自力解決する割合）と誤答率のトレードオフ曲線を実測し、誤答コストが高い業務ほど棄権寄りに閾値を設定します。 ✅ 選定条件 - 向き：顧客対応・専門領域・リスクの高い助言など誤答コストが高い業務 - 不向き：誤りが無害なブレインストーミングや探索的な対話 ⚠️ 落とし穴 - 閾値が高すぎると人間への丸投げが増え、エージェント導入の意味がなくなる - 閾値が低すぎると誤答が増え、信頼を失う - エスカレーション時に文脈を引き継がないと、顧客が同じ説明を繰り返す羽目になる 🛠️ 実装方針 1. 信頼度スコアを「自己評価＋検索ヒット関連度＋検証器合否」の複合で算出するスコアリング関数を実装します 2. 閾値未満時のwarm handoffでは、会話履歴・抽出済みエンティティ・試行済み回答をZendeskチケットまたはSlackスレッドに自動転送します 3. エスカレーション経路をZendesk（顧客対応）、Slack（社内）、PagerDuty（緊急）の3段階で設計します 4. 封じ込め率と誤答率のトレードオフ曲線を週次で可視化し、ドメインごとに閾値を調整します 5. 棄権理由を構造化ログに記録し、頻出する棄権パターンからナレッジベースの改善ポイントを特定します #AIエージェント# #エンタープライズアーキテクチャ#

# AIエージェント開発の意思決定ポイント # 温度（Temperature） 🎯 ポイント 温度パラメータ、全部のタスクに同じ値を設定していませんか？ エージェントシステムにおける温度は「創造性のつまみ」ではありません。構造化出力、ツール呼び出し、ユーザー応答 -- 経路ごとに最適な温度は全く違います。1つのエージェント内でも使い分けるのが基本です。 📋 概要 温度はLLMが次のトークンを選ぶ際の確率分布の「尖り具合」を制御するパラメータです。温度0に近いほど最も確率の高いトークンが選ばれやすくなり、出力は決定論的で安定します。温度を上げると確率分布が平坦化し、低確率のトークンも選ばれるようになるため、出力の多様性と創造性が増します。 AIエージェントでは、構造化出力を生成する場面、ツール呼び出しの引数を組み立てる場面、自由形式のテキストを生成する場面で求められる温度が異なります。温度は単一の固定値ではなく、タスクの種別に応じて動的に切り替えるべき変数です。 🔍 意思決定のポイント 温度の設定は主にtask_variability（タスクの定型度）で決まります。判定フローは明快です 🧭 1. 構造化出力（JSON/関数呼び出し）か？ → 0.0〜0.3 2. 正確性が最優先（事実抽出・分類・要約）か？ → 0.2〜0.5 3. 対話・説明・コミュニケーションか？ → 0.5〜0.7 4. 創作・ブレインストーミング・候補生成か？ → 0.7〜1.0 加えて、failure_cost（失敗コスト）が高いほど温度の上限を下げ、cost_sensitivity（コスト感度）が高い環境ではリトライによるコスト増を見込んで温度を抑えます。 💡 要点と詳細 タスク別の目安値 📊 - 構造化出力（JSON / function calling） → 0.0〜0.3。スキーマ違反の最小化が最優先 - 分類・抽出・データ変換 → 0.0〜0.2。正確性と再現性が命 - 要約・説明・カスタマー対応 → 0.5〜0.7。自然さと正確性のバランス - 創作・ブレスト・候補生成 → 0.7〜1.0。多様性が価値の源泉 - ツール引数の生成 → 0.0〜0.2。関数名・引数名の正確性が不可欠 - 計画・推論 → 0.3〜0.6。多少の探索は有益だが論理の一貫性を保つ 構造化出力の温度はまず0から始めてください。0でもスキーマ違反が出る場合はプロンプトかスキーマの問題です。温度を上げて「偶然正しい出力が出る」ことに依存してはいけません 🚫 ⚖️ トレードオフ 温度が低すぎると対話が機械的で紋切り型になります 🤖 同じ質問に毎回同じ回答を返し、「テンプレート応答」の印象を与えます。Best-of-Nサンプリングも候補がほぼ同一になり、N倍のコストだけかかって実質N=1と同じ結果に。 温度が高すぎると構造化出力が壊れ始めます 💥 JSONのフィールド名が揺れたり、型が合わなくなったり。ハルシネーションも増加し、固有名詞・数値・日付の正確性が崩壊します。ツール呼び出しの不安定化、再現性の喪失も深刻な問題です。 温度によるリトライコストの増加も計測してください。スキーマ違反率が概ね5%を超えたら温度を下げることを検討しましょう。 🛠️ ユースケース エージェント内の経路ごとに温度を変えるのが基本 🔀 計画ステップは0.3〜0.5、ツール呼び出しの引数生成は0.0〜0.2、ユーザー向け応答は0.5〜0.7。モデルを切り替える際に温度も同時に切り替えると自然です。 Best-of-Nを使うなら温度を上げる必要があります。温度0でN=5を生成しても、ほぼ同一の候補が5つ返るだけです。N>1のときは0.5〜0.8に設定し、多様な候補の中からJudgeが最良を選ぶ構成にします。 top_pとの併用には注意 ⚠️ 温度とtop_pを両方変更すると効果が掛け算になり、予測困難な挙動を示します。原則としてどちらか一方だけを調整してください。 #AIエージェント# #ソフトウェアアーキテクチャ#

AIが「仕事を奪う」という問いより、もっと本質的な問いがあります。 多くの企業がAI導入の成否を「コスト削減」「人員削減」で測ってきました。しかし2024年ノーベル経済学賞受賞のSimon Johnson教授（MIT）は、それを「あまりにも簡単すぎる選択肢」と呼びます。機械で人を置き換えることに経営的な想像力はほとんど必要ない。そして、その安易さこそが企業が本来得られるはずのビジネス価値を取りこぼしている原因だ、と。 Acemoglu・Autor・JohnsonらMIT経済学者とBrookings研究所が示す「プロ・ワーカーAI」の概念は、別の問いを中心に据えます。「このAIは人間の専門性をより価値あるものにするか、それとも不要にするか？」Brookingsは技術を5種類に分類し、「新タスク創出型」だけが明確に労働者に有益だと論じます。AIが従来存在しなかった種類の仕事を生み出すとき、それは単なる省力化とはまったく異なる価値を持ちます。 現実の事例がこの違いを鮮明にします。Schneider Electricは電気技師向けのAIトラブルシューティングツールを開発し、保守報告書の作成時間を半減させながら、作業員がより複雑な問題解決に集中できる環境を整えました。米国特許商標庁では、AI検索ツールが審査官の概念的文献探索を精緻化し、専門的判断の価値を高める方向で機能しています。AIツールが増殖する時代、競争優位は技術そのものではなく「技術を中心に仕事をどう再設計するか」に移行しつつあります。 タイトル: Pro-Worker AI, Explained URL: 企業に問われているのは「AIで何人削れるか」ではなく、「AIで自社の人材がどんな新しいことをできるようになるか」です。 #AIと労働# #組織設計#