# AIエージェントをエンタープライズシステムに組み込む意思決定ポイント # 汎用大モデル vs 小型FT｜推論エンジンの選択 🎯 ポイント エージェントの推論エンジン、GPT-4クラスの汎用大モデルをプロンプトで制御するか、タスク特化の小型ファインチューニング（FT）モデルを使うか。「大きいほど賢い」は正しいですが「大きいほど正解」ではありません。タスクの多様性・呼び出し頻度・コスト制約・変化の速度によって最適解が変わります。多くのエンタープライズでは、まず汎用大モデルで始めてログから教師データを蓄積し、高頻度タスクから順にFTに置き換える段階的移行が現実的な最適解です🔑 📋 概要 汎用大モデル＋プロンプトは、タスクが多様で事前に列挙しきれない場合、ビジネス要件の変化が速い場合、新しいツールやAPIの追加にプロンプトの変更だけで対応したい場合に強みを発揮します。小型FTモデルは、タスクが狭く定義され入出力パターンが安定している場合、呼び出し頻度が高くコスト削減が重要な場合、レイテンシ要件が厳しい場合に適しています。両者は排他ではなく、ルーター＋専門モデルというハイブリッド構成で組み合わせるのがエンタープライズの標準的なアプローチです📊 🔍 意思決定のポイント 判断フローは以下の通りです。 タスクの種類が10以上あり頻繁に新しいタスクが追加されるなら、汎用大モデルを選びましょう。プロンプト変更だけで新タスクに対応できる柔軟性が決定的な優位性です。 月間リクエスト数が数十万件以上なら、小型FTのコストメリットを試算してください。API呼び出しコストだけでなく、学習コスト・GPU運用コスト・教師データ管理コストも含めた総所有コストで比較することが重要です。 レイテンシ要件がP95で500ms以内なら、小型FTを優先的に検討しましょう。大規模モデルの推論時間では達成困難なケースがあります。 教師データを数千件以上用意・継続的に更新できないなら、汎用大モデルに留めましょう。不十分な教師データでFTしても、汎用大モデルの精度を下回ります。 ビジネス要件の変更頻度が月次以上なら、再学習コストを考慮して汎用大モデルを維持する方が有利な場合が多いです⚡ 💡 要点と詳細 ハイブリッド構成の3パターンを理解してください： ルーター＋専門モデル — 汎用大モデルでリクエストの意図を分類し、定型タスクは小型FTモデルにルーティングします。意図分類のコストは小さく、専門タスクの推論コストを大幅に削減できます。Slack Botが全社横断の質問を受け付け、チケット分類は小型FT、複雑な調査は汎用大モデルという振り分けです。 FTで下書き、大モデルで仕上げ — 小型FTモデルで高速に下書きを生成し、品質が重要なケースだけ汎用大モデルで検証・修正します。コストと品質のバランスを取る実用的なパターンです。 段階的移行 — 初期はすべて汎用大モデルで運用し、呼び出しログから教師データを蓄積して、高頻度タスクから順に小型FTに置き換えます。これが最もリスクが低く、多くのエンタープライズが採用するアプローチです🔄 ⚖️ トレードオフ 早すぎるFT投資は最もよくある失敗です。十分なログが溜まる前にFTモデルを構築し、精度が汎用大モデルを下回ります。最低でも3か月分のログを蓄積してからFTを検討してください。PoC段階でFTに手を出すのは時期尚早です😰 FTモデルの陳腐化も深刻です。ビジネスルールや製品ラインナップが変わったのに教師データが更新されず、古い知識で回答し続けます。再学習パイプラインの自動化は、FTモデルの運用における必須投資です。 コスト比較の誤りも多発します。API呼び出しコストだけで比較し、FTモデルの学習コスト・推論インフラ（GPU）運用コスト・教師データ管理コストを見落とします。TCO（総所有コスト）で比較しないと判断を誤ります。 品質評価の欠如も見逃せません。FTモデルの精度を定期的に評価せず、モデルドリフトに気づきません。汎用大モデルとのA/Bテストを継続的に行う仕組みが品質保証の基盤です⚠️ 🛠️ ユースケース 全社ヘルプデスクエージェント（Slack Bot）：IT・総務・人事・経理の幅広い問い合わせに対応。汎用大モデルで意図を分類し、チケットカテゴリ・優先度の自動振り分け（月間数万件）は小型FTにルーティング。複雑な調査や新しい種類の質問は汎用大モデルで処理します📚 チケット分類エージェント（Zendesk連携）：毎日数万件のサポートチケットのカテゴリ・優先度・担当チームを自動分類。呼び出し頻度が高く入出力パターンが安定しているため、小型FTが最適。教師データは月次で更新し、汎用大モデルとのA/Bテストで精度を監視します🏢 商品レビュー分析エージェント（Shopify連携）：商品レビューの感情分析とタグ付けを小型FTでバッチ処理。レビューから得られた顧客インサイトの要約は汎用大モデルで生成。定型的な分類はFT、創造的な分析は汎用大モデルという明確な役割分担です🔧 実践のコツ：「まず汎用大モデルで始めて、ログを溜める」が鉄則です。3か月分以上のログから高頻度タスクを特定し、教師データを構築し、FTの効果を汎用大モデルとのA/Bテストで検証してから置き換えてください。FTへの移行はデータドリブンで判断しましょう💪 #AIエージェント# #エンタープライズアーキテクチャ#

# OpenAI Agent SDKの便利だけど知られていない機能 🌍 複数の LLM プロバイダを 1 つのエージェントシステムで混在させたいと思ったことはありませんか？ `MultiProvider` を使えば、モデル名のプレフィックスで自動的にプロバイダをルーティングできます。 📌 タイトル：MultiProvider による接頭辞ルーティング 🔗 URL： 🧩 概要 `MultiProvider` は、モデル名のプレフィックス（例：`openai/gpt-4.1`）に基づいてリクエストを適切なプロバイダに自動ルーティングします。`openai_prefix_mode="model_id"` を設定すると `openai/...` をそのままモデル ID として扱い、`unknown_prefix_mode="model_id"` で未知のプレフィックスもモデル ID としてルーティングします。`openai_use_responses_websocket=True` で WebSocket トランスポートも有効化可能です。 🛠 使い方 ```python from agents import Agent, MultiProvider, RunConfig, Runner provider = MultiProvider( openai_base_url="", openai_api_key="...", openai_use_responses_websocket=True, openai_prefix_mode="model_id", unknown_prefix_mode="model_id", ) agent = Agent( name="Assistant", instructions="Be concise.", model="openai/gpt-4.1", ) result = await agent, "Hello", run_config=RunConfig(model_provider=provider), ) ``` 🏗 本番システムへの組み込み方 ・コストやレイテンシに応じて、エージェントごとに異なるプロバイダのモデルを割り当てる ・OpenRouter などの統合ゲートウェイと組み合わせ、`openai_prefix_mode="model_id"` でプレフィックス付きモデル名をそのまま渡す ・`RunConfig(model_provider=provider)` で実行時にプロバイダを切り替え、A/B テストを実施する ・WebSocket を有効にして、対応プロバイダでのストリーミング性能を向上させる 💡 ユースケース 🔀 タスクの難易度に応じた GPT-4.1 / GPT-5.5 の使い分け 🌐 OpenRouter 経由での複数プロバイダへのアクセス統合 💰 高コストモデルと低コストモデルのハイブリッド運用 🧪 異なるモデル間での品質比較テスト ⚠️ 注意点 デフォルトでは `openai/...` は OpenAI プロバイダのエイリアスとして扱われ、未知のプレフィックスは `UserError` を発生させます。OpenRouter など外部ゲートウェイを使う場合は、必ず `openai_prefix_mode` と `unknown_prefix_mode` を `"model_id"` に設定してください。プロバイダごとに対応する機能（ツール呼び出し、構造化出力など）が異なる点にも注意が必要です。 ✨ MultiProvider で、複数のモデルを自在に組み合わせたエージェントシステムを構築しましょう。 #OpenAIAgentSDK# #AIAgent#

# OpenAI Agent SDKの便利だけど知られていない機能 🌍 SDK が直接サポートしていないプロバイダ固有のパラメータを、エージェントに渡したいと思ったことはありませんか？ `extra_args` を使えば、`ModelSettings` に任意のプロバイダ固有フィールドを追加できます。 📌 タイトル：extra_args の受け渡し 🔗 URL： 🧩 概要 `ModelSettings` の `extra_args` パラメータに辞書を渡すことで、SDK のトップレベルプロパティとして公開されていないプロバイダ固有のリクエストフィールドをモデルに送信できます。例えば OpenAI Responses API の `service_tier` や `user` などを指定可能です。これにより、SDK のアップデートを待たずに新しい API パラメータを利用できます。 🛠 使い方 ```python from agents import Agent, ModelSettings agent = Agent( name="English agent", instructions="You only speak English", model="gpt-4.1", model_settings=ModelSettings( temperature=0.1, extra_args={ "service_tier": "flex", "user": "user_12345", }, ), ) ``` 🏗 本番システムへの組み込み方 ・`service_tier` でコスト最適化（例：`"flex"` で低優先度バッチ処理を安価に実行） ・`user` フィールドでユーザー単位のトラッキングと不正利用検知を有効化する ・新しい API パラメータが追加された際、SDK の更新を待たずに即座に利用可能 ・環境変数や設定ファイルから `extra_args` を動的に構築し、デプロイ環境ごとに調整する 💡 ユースケース 💰 `service_tier: "flex"` でバッチ処理のコスト削減 👤 `user` フィールドによるユーザー単位の利用量追跡 🔧 プロバイダの新機能をリリース直後から活用 🏢 マルチテナント環境でのテナント別パラメータ注入 ⚠️ 注意点 同じリクエストフィールドを `ModelSettings` の直接プロパティと `extra_args` の両方で設定しないでください。重複設定は予期しない動作を引き起こす可能性があります。また、`extra_args` に渡す値はプロバイダの API 仕様に準拠している必要があり、SDK 側でのバリデーションは行われません。 ✨ extra_args で、SDK の枠を超えたプロバイダ固有の最適化を手軽に適用しましょう。 #OpenAIAgentSDK# #AIAgent#

ウィスコンシン大学マディソン校とUCサンタバーバラ校の研究チームが、複数のAIエージェント同士が協力する場面で「探索」がうまく機能していないことを示す論文を発表した(https://arxiv[.]org/pdf/2607.11250)。 まず単純な設定で確かめている。1つのAIエージェントに、成功確率60%のピアAと50%のピアBのどちらかへ作業を繰り返し委任させる「2本腕バンディット」問題(手持ちの選択肢を試行錯誤しながら良い方に絞り込んでいく、探索と活用のトレードオフを扱う古典的な意思決定問題)を50ラウンド行わせた。理想的には最初は両方を試しつつ、徐々に成功率の高いピアAへ寄せていくのが正解になる。ところがQwen2.5-7B、GPT-4、GPT-5のいずれも、最初の数ラウンドでどちらか一方に固定してしまい、そのまま50ラウンド動かなくなる「早すぎる決め打ち」を起こした。比較用に置いた古典的な探索アルゴリズムUCB1(不確実性の高い選択肢を楽観的に評価し、試行回数を自然に分散させる手法)はきちんと両方を試しながら徐々に絞り込んでおり、対照的だった。 著者らはこれを「マルチエージェント探索問題」として定式化し、部分観測確率ゲーム(POSG、各プレイヤーが相手の能力や状態を完全には観測できないまま、同時に意思決定を繰り返すゲーム理論の枠組み)としてモデル化した。興味深いのが、エージェントに「探索と活用のバランスを取れ」とプロンプトで明示的に指示するだけの手法(In-Context Exploration)が、複数の文書をまたいで証拠を集めないと解けない質問応答ベンチマークHotpotQAを使い10体のエージェントに文脈を分担させた設定では、ランダムにピアを選ぶより成績が悪くなったことだ。プロンプトで頼むだけでは探索は直らず、構造的な仕組みが要ることを示している。モデルの種類が異なる4体(GPT-5、Qwen2.5-7B、Llama3.1-8B、Mistral-7B)を混ぜ、大学院レベルの専門知識を問う難しい選択式ベンチマークGPQAで解かせた実験でも同じ傾向が出た。最も強いはずのGPT-5でさえ、297回の相互作用のうち294回をQwen2.5-7Bに固定し、他のエージェントをほとんど試さなかった。 そこで著者らが提案するのがMACE(Multi-Agent Contextual Exploration)。各エージェントの選択を文脈付きバンディット問題として扱い、ピアの回答が自分と違うか(応答の多様性)、他のピアと比べて特徴的か(ピア間の異質性)、過去の成績はどうか、といった関係性を特徴量にしてLinUCB(不確実性ボーナス付きで期待報酬を推定する手法)でピアを選ばせる。HotpotQAで学習したパラメータを、追加学習なしで別の質問応答ベンチマーク2WikiMultihopQAに転用しても全ベースラインを上回った。理論面では、MACEの累積後悔(最適な選択との差の総和)がO(√(T log T))に収まる一方、探索しない貪欲な方策はΩ(δT)の後悔を負うと示されており、δはエージェント間の能力差の大きさを表す。エージェントが多様であるほど、探索の価値は際限なく大きくなる計算だ。 個々のモデルの賢さを積み上げても、「誰に何を聞くか」を決める仕組みが伴わなければ組織としての精度は頭打ちになる、という指摘として読める。

AIに3Dの部屋を作らせるなら、完成例だけでなく「どの修正が効いたか」と「なぜ使いにくいか」も学ばせたい（ 家具がぶつかっていなくても、椅子の向きが机と合わない、窓への道を塞ぐ、といった配置は使いにくい。そこで、作る過程の観察・判断・操作を約3.5万件、複数の部屋を比べる批評データを約1.5万件用意した。作業記録からは、最終状態を保ちながら無効な修正を取り除いている。 学習では、同じ部屋から複数の編集案を試し、Critic（部屋の物理的な成立、使い勝手、配置のまとまりを評価するモデル）が比較する。候補のどれがよいかに加え、編集前より本当に改善したかも報酬にする。学習中はCriticを固定し、作る側を更新する。 お手本をまねる学習だけのScene-Builderと比べ、物の向きの誤りを直すのに5回以上の修正が必要だった割合は40%から7%へ。窓へのアクセスを塞ぐ誤りでは21%から5%へ下がった。これは成功率ではなく、修正回数についての比較。 さらに生成時にも4案からCriticが選ぶと品質が上がる。ただし、部屋の見た目や機能の評価にはGPT-4を使い、批評データには配置を意図的に崩した例も含む。人間の生活空間での使いやすさを直接実証したわけではない。 手順を長く残すことより、効果のある修正を残し、次の案を選べる評価役を育てる。3D制作に限らず、エージェントの作業経験を学習へ戻すときにも参考になる設計だと思う。

# OpenAI Agent SDKの便利で実践的な使い方 🌍 エージェントの「お財布事情」を可視化しましょう。トークン使用量の追跡で、テナント別課金もステップ別モニタリングも実現できます。 Usage API を使えば、実行全体のトークン消費量から、ツール呼び出し・ハンドオフごとの内訳まで、きめ細かくコストを把握できます。 📌 タイトル：Usage 🔗 URL： 🧩 概要 OpenAI Agent SDK の Usage 機能は、エージェント実行のトークン消費を追跡するための仕組みです。`result.context_wrapper.usage` で実行全体の合計トークン数を取得でき、`result.context_wrapper.usage.request_usage_entries` でステップごと（ツール呼び出し・ハンドオフ・ガードレール）の内訳を確認できます。さらに RunHooks の `on_agent_end` でリアルタイムにログを記録したり、サードパーティモデル使用時に `ModelSettings(include_usage=True)` で使用量レポートを有効化したりできます。 🛠 使い方 `Agent(name="Assistant", instructions="ユーザーの質問に回答してください。")` でエージェントを作り、`result = await "量子コンピュータについて教えてください")` を実行します。` で合計・入力・出力トークン数を取得できます。`result.context_wrapper.usage.request_usage_entries` をループすれば、各リクエストの `entry.input_tokens` と `entry.output_tokens` でステップごとの内訳も確認できます。 🏗 実践的な使い方 **テナント/ユーザー別コスト計算** SaaS で「テナントごとにいくら使ったか」を記録し、課金や予算管理に活用するパターンです。 `handle_request(tenant_id, user_id, message)` のような関数で `result = await message)` を実行し、`calculate_cost(model="gpt-4.1", input_tokens=result.context_wrapper.usage.input_tokens, output_tokens=result.context_wrapper.usage.output_tokens)` でコストを算出、`await billing_db.record(tenant_id=tenant_id, user_id=user_id, total_tokens= cost_usd=cost, timestamp= でテナント別に記録します。 **ステップ別モニタリング** `request_usage_entries` で、どのツール呼び出しやハンドオフがトークンを消費しているかを特定します。 `result = await "売上レポートを作成して")` の後、`result.context_wrapper.usage.request_usage_entries` を `enumerate` でループし、各ステップの `entry.input_tokens` と `entry.output_tokens` を確認します。`entry.input_tokens > 5000` のような閾値で警告を出せば、トークン消費の多いステップを特定できます。 **RunHooks でリアルタイムログ** `on_agent_end` フックでエージェント終了時に使用量をログに記録します。 `RunHooks` を継承した `UsageLoggingHooks` クラスを作り、`on_agent_end(self, context: RunContextWrapper, agent: Agent, output)` メソッドで `context.usage` からトークン使用量を取得し、`"agent_completed", agent_name= total_tokens= ...)` で構造化ログに記録します。`await "質問", hooks=UsageLoggingHooks())` のように `hooks` パラメータで渡します。 **サードパーティモデルでの使用量レポート有効化** OpenAI 以外のモデルアダプタを使う場合、明示的に使用量レポートを有効にする必要があります。 サードパーティモデルでは `Agent(name="ThirdPartyAgent", instructions="...", model=my_custom_model_adapter, model_settings=ModelSettings(include_usage=True))` のように `ModelSettings(include_usage=True)` を明示的に設定して、使用量レポートを有効化します。 💡 ユースケース 💰 テナント別・ユーザー別のトークン消費をDBに記録し、従量課金の基盤を構築 📊 request_usage_entries でステップ別のトークン消費を可視化し、コスト最適化のボトルネックを特定 🔔 RunHooks の on_agent_end で使用量を構造化ログに記録し、リアルタイムでダッシュボード監視 🔌 サードパーティモデル利用時に ModelSettings(include_usage=True) で使用量追跡を漏れなく有効化 ⚠️ 注意点 - ` はリトライやガードレール再実行分も含まれるため、表示上のステップ数より多くなる場合があります。 - サードパーティモデルでは `include_usage=True` を設定しないと使用量がゼロで返ることがあります。アダプタのドキュメントを確認してください。 - コスト計算はモデルの料金体系に依存します。モデルごとの入力/出力トークン単価を正確に反映させましょう。 ✨ トークン使用量を3つのレベル（合計・ステップ別・フック）で追跡すれば、コスト管理も品質監視も万全です。まずは result.context_wrapper.usage から始めて、必要に応じてステップ別やフックでの追跡を追加していきましょう！ #OpenAIAgentSDK# #AIAgent#

🧬 エージェントが自分自身を「安全に」進化させるには、プロトコルそのものを作り直す必要がある——MCPやA2Aに足りないピースを埋める自己進化プロトコルが登場しました。 タイトル: Autogenesis: A Self-Evolving Agent Protocol URL: 🧬 概要 Autogenesis Protocol（AGP）は、LLMエージェントが実行中に自分のプロンプト・ツール・方策などを動的に改善できるようにする自己進化プロトコルです。中心思想は「何が進化するか」と「どう進化するか」を分離することです。 ❓ 解決する課題 既存プロトコル（Anthropic MCP、Google A2A）は接続や呼び出しは標準化しますが、進化に不可欠な要素が欠けています。 ・リソースがエージェントのコードと密結合している ・進化ステップのバージョン管理やロールバックが無い ・場当たり的な修正で、厳密な制御ループを成す標準オペレータが無い 💡 方法論と提案手法 AGPは2層構造です。 ・RSPL：プロンプト・エージェント・ツール・環境・メモリの5種を、状態・ライフサイクル・バージョン管理されたインターフェースを持つ「登録リソース」として扱う ・SEPL：進化を型付きの合成可能オペレータで形式化し、すべての変更をRSPL経由でバージョン管理・可逆にする この上に構築したAGSは、Agent Bus上でサブエージェントを並行実行し、失敗の兆候があればReflect→Select→Improve→Evaluate→Commitのループで自己改善します。 🎯 ユースケース 長期計画や多様なツール利用を要するエージェント開発に有効です。改善の系譜が残りロールバックできるため、壊れやすいグルーコードを避けつつ安全に自己進化を運用できます。 📊 実験結果 ・科学・数学：弱いモデルほど効果大。gpt-4oはAIME25で+100%、gpt-4.1はAIME24で+71.38%。一方で飽和した強モデルは天井効果で伸び小 ・GAIA：Test 79.07%→89.04%（+12.61%）。難易度Lv3で+33.34%と難問ほど効果大 ・コード生成：C++は合格79→99、TLEエラー9→0、実行効率+46.4%。プロンプトと出力の同時進化が最良でした #AIエージェント# #自己進化#

🧠 「コンテキストを読む」から「コンテキストからスキルを身につける」へ。人手の注釈も外部フィードバックも使わず、自己対戦だけでLLMが文脈固有のスキルを獲得する手法です。 タイトル: From Context to Skills: Can Language Models Learn from Context Skillfully? URL: 📝 概要 LLMは事前学習にある知識は得意ですが、新規で専門的な文脈には弱いです。本論文は、人手注釈や外部フィードバックなしに、文脈固有のスキルを自律的に発見・洗練するCtx2Skillを提案します。 ❓ 解決する課題 長く専門的な文書ではアノテーションのコストが高すぎます。さらにコーディングと違い、コンテキスト学習には実行フィードバックのような検証信号がなく、自動的なスキル構築が困難でした。 💡 方法論と提案手法 ・凍結したLMによる5役割のマルチエージェント自己対戦を、M=5タスクにN=5回反復します ・Challengerが弱点を突くタスクとルーブリックを作り、Reasonerが解き、Judgeが合否を判定します ・ProposerとGeneratorが失敗を診断してスキル更新を合成します ・Cross-Time Replayで、難問と易問の性能の積を最大化し、反復をまたいで最も汎化するスキルセットを選びます 🎯 ユースケース 専門領域の長文ドキュメントを与えて、その場でモデルに必要なスキルを獲得させる用途に向きます。ドメイン固有の知識へ素早く適応させたい実務に直結します。 📊 実験結果 ・CL-Bench（500コンテキスト、1,899タスク）で、GPT-4.1の解答率が11.1%→16.5%に向上 ・GPT-5.1は21.1%→25.8%、GPT-5.2は18.2%→21.4% ・強いモデルのスキルが弱いモデルへ転移し、GPT-5.1のスキルをGPT-4.1に適用すると16.1% ・適用後のGPT-4.1（16.5%）は、拡張なしのGemini 3 Pro（15.8%）を上回りました #LLM# #InContextLearning#

ハーネスエンジニアリングのアンチパターン AP3. 足場のラチェット（The Scaffolding Ratchet） 🎯 ポイント 失敗するたびにルールが足され、何ひとつ外されない。気づけばRube Goldberg装置のようなハーネスが、モデルと戦い始めています。「一度効いた」は「今も要る」を意味しません。 ❗ 発生する課題 ルール・ステップ・ガードレールが際限なく蓄積し、ハーネスが複雑な迷宮になります。モデルの能力が向上しても過去の足場が性能の天井を作り、誰も全体を把握できないため改善も困難になります。 🔍 メカニズムと症状 このアンチパターンが蔓延するのは、各ルール追加が局所的には正当（「あの事故を一度は防いだ」）であり、削除はリスクに見えるからです。しかし、足場は一方向にしか回らないラチェットになり、Rube Goldberg装置に堕します。モデルが賢くなると、過去の足場はモデルの推論を不必要に制約する性能の天井になります。症状としては、誰も全ルールを把握していない、新しいルールが古いルールと矛盾する、モデルを更新しても性能が上がらない（足場が制約しているため）、ハーネスの修正が怖くて誰も触れない、といった現象が見られます。 📋 シナリオ ・あるバグで「必ずファイルAを先に読め」というルールを追加。別のバグで「ファイルBを先に読め」を追加。さらに別のバグで「計画を必ず3段階に分けろ」を追加。結果、エージェントは毎回不必要な手順を踏み、簡単なタスクでも遅くなる。 ・モデルをGPT-4からClaude Opusに更新したが、GPT-4の弱点を補うために追加した足場がClaude Opusの強みを殺し、性能が変わらない。 ・ハーネスのルールファイルが500行に膨れ上がり、新しいチームメンバーが理解不能。改善提案をしても「前に事故があったから」と却下される。 🛡 回避方法 ・足場にもガベージコレクションを導入し、モデル更新ごとに全ルールを棚卸しして不要なものを削除します ・各ルールに「なぜ追加されたか」「いつ追加されたか」「どのモデルバージョンで追加されたか」を記録します ・定期的に足場を外した状態でベンチマークを実行し、本当に必要な足場だけを残します ・「ルール追加」だけでなく「ルール削除」も改善アクションとして意識的に実施してください #HarnessEngineering# #AIAgent#