🔄Loop Engineeringとはなにか？ もう「AIにプロンプトを打つ」作業は終わりにしませんか？これからは、エージェントを自律的に回す仕組みそのものを設計する時代です。AIコーディングのパラダイムシフトの正体に迫ります。 💡 1. プロンプトからシステム設計への転換 従来のAIコーディング（AI-assisted Coding）は、人間がループの「中心」にいました。 👨‍💻 これまでのアプローチ: 人間がコンテキストを考え、プロンプトを打ち、AIの出力を読み、手元でテストを実行し、エラーが出たら再度プロンプトを打つ。AIは「高機能な関数」や「道具」であり、制御の主体は常に人間です。 🔄 ループエンジニアリング: 人間はループの「外側」に出て、システム全体のデザイナー（作者）になります。仕事の検知、AIへのコンテキスト注入、出力の自動テスト、進捗の記録、次のステップの判断という一連のライフサイクルを小さなプログラムに実行させます。 ここで重要なのは、AIモデルがシステムにおける「サブルーチン（部品）」へと降格し、代わりに環境（テストスイートやリポジトリの状態）からのフィードバックをループ処理する構造へ進化したという点です。 ⚙️ 2. ループを駆動する5つのコアコンポーネント＋1つの記憶 抽象的な概念を動くシステムに落とし込むため、ループは以下のコンポーネントに分解されて設計されます。 ① ⚡ 自動化（Automations） ループの心臓部であり、発火トリガーと停止条件を定義します。 ツール（Claude CodeやCodexなど）では、単に定期実行する /loop だけでなく、明確な終了条件（例：「すべてのテストがパスするまで」）を満たすまでAIを回し続ける /goal コマンドなどがこれに該当します。条件が達成されるか、ハードストップ（予算や上限回数）に達するまで回り続けます。 ② 🌳 ワークツリー（Worktrees） 複数のAIエージェントが並列で動く場合、同じディレクトリで作業するとファイルの衝突（コンフリクト）が発生します。これを防ぐため、Gitの worktree 機能を使い、エージェントごとに独立した作業ディレクトリとブランチを隔離して自動生成します。機械的な衝突を回避し、並列性を担保する基盤です。 ③ 🧠 スキル（Skills） リポジトリのルールやコンテキストをカプセル化したものです。 通常、AIは実行ごとに前回の文脈を忘れますが、SKILL.md のようなファイルに「このプロジェクトのビルド手順」「命名規則」「過去の障害から得た注意点」を明文化しておくことで、AIは毎実行時にそれを読み込み、プロジェクト固有のシニアエンジニアのような振る舞いを固定化できます。 ④ 🔌 プラグイン／コネクタ（Connectors） filesystem（ローカルファイル）しか見えないAIを、本物の開発環境につなぐ架け橋です。 Model Context Protocol（MCP）などをベースに、GitHub（PR作成やIssue取得）、Linear/Jira（チケット更新）、Slack（人間への通知）、Sentry（エラーログの取得）と接続します。これにより、AIが「修正案を出す」だけでなく「Issueを読んで、コードを直し、PRを送り、Slackに報告する」というエンドツーエンドの行動が可能になります。 ⑤ 🤖 サブエージェント（Sub-agents） 役割を分担された独立したAIインスタンスです。「コードを書く役割（Maker）」と「コードを検証・レビューする役割（Checker）」を完全に分離します。 ➕ 💾 記憶：状態ファイル（State File） 地味ですが、ループの成否を分ける最も重要な要素です。STATE.md やJSONファイル、あるいは外部のチケット管理システムに「現在どのブランチが進行中で、何が完了し、次に何をすべきか」を永続化します。「エージェントは忘れるが、リポジトリは忘れない」という原則に従い、昨日の続きを今日のループが再開できるようにします。 🕰️ 3. なぜ「ただのcron（定期実行）」ではないのか？ 懐疑派から「1975年に発明されたcronジョブのリブランド（名前の付け替え）に過ぎないのではないか」という指摘があります。これは半分正解で、半分は間違いです。 スケジュールやトリガーのレイヤーは確かにcronそのものです。しかし、従来のcronは「固定されたスクリプトを機械的に実行するだけ」でした。 ループエンジニアリングが異なるのは、ループの真ん中に「状況を動的に判断する意思決定者（LLM）」がいる点です。 テストが落ちたとき、どのファイルをどう修正すべきか、コンテキストをどう組み立て直すかという分岐は、ハードコードされた if/else ではなく、AIの推論によって動的に決定されます。工学的な面白さは、この「崖から落ちるかもしれない不確実な意思決定者」の周りを、いかに硬牢な自動テストやガードレールで固めるかというシステムデザインにあります。 ⚠️ 4. コストと運用リスクの現実 熱狂的な議論で無視されがちなのが、経済性とセキュリティの現実です。 💸 膨大なトークン消費（コスト） コード生成自体は安価になりましたが、ループを回すと「コンテキストの再読み込み」「リトライの繰り返し」「探索パターンの実行」により、トークン消費量が爆発的に増加します。 実際に、米Uberではエンジニア1人あたり月1,500ドルの上限を設けたにもかかわらず、年間のAI予算をわずか4ヶ月で使い切った事例があります。「最大反復回数」「金額上限」「進捗ゼロ検知による強制終了」の3つのガードレール（ハードストップ）の設計が不可欠です。 🛡️ 攻撃面の拡大（セキュリティ） 無人で動くループは、無人で動く攻撃面（アタックサフェース）になります。AIコーディングツールに起因するCVE（脆弱性）が多数確認されており、コマンドインジェクションやSSRF、XSSのリスクがあります。また、外部から取り込んだ「スキル」の説明文がプロンプトインジェクションの経路になり、デバッグログ経由で認証情報（資格情報）が漏洩するケースも監査で報告されています。 🧩 理解の負債（Comprehension Debt） AIが高速でコードを書き、テストが通ってマージされ続けると、リポジトリ内のコードベースと「人間の理解度」の距離がどんどん離れていきます。これを「理解の負債」と呼びます。最も高くつくのはトークンの請求書ではなく、「チームの誰も読んだことがなく、構造を理解していないシステム」をある日突然人間がデバッグしなければならなくなるコストです。 🛠️ 5. 実践：4条件テストと最小実用ループ（MVL）の構築 ループエンジニアリングを実務に導入する際は、厳格な仕分けとステップが必要です。 📋 導入のための4条件テスト 1. タスクが繰り返されるか？（週1回未満なら、手動プロンプトや使い捨てスクリプトの方が早い） 2. 検証が完全に自動化されているか？（テスト、型チェック、Linter、ビルドが悪い出力を100%機械的に弾けるか。これがないと人間がレビューの椅子に縛り付けられる） 3. トークン予算が無駄を吸収できるか？（従量課金で予算に余裕がない場合は無謀） 4. エージェントが環境を操作する道具を持っているか？（ログ確認や再現環境など） 🚀 最小実用ループ（MVL）から始める手順 最初から複雑なマルチエージェントを組むとシステムは確実に崩壊します。以下の順番でボトムアップに構築します。 1. 手動実行の確実化: 1回の手動プロンプトと環境操作で、タスクが完全に完了することを確認する。 2. スキルの文書化: その際のコンテキストや制約を SKILL.md にまとめる。 3. ループのラップとゲート配置: AIが書いたものを自動テスト（ゲート）にかけ、失敗したらAIに戻すという1サイクルを組む。 4. スケジューリング: 最後にそれをcronやイベントトリガーで自動化する。 🎯 レバレッジの支点は「コードを書くこと」から「コードを書く仕組みを定義し、検証すること」へ移動しました。人間は、AIが自分の宿題を甘く採点しないよう、冷徹な「検証ゲート」を設計するエンジニアであり続ける必要があります。

💭 長いコンテキストを読むAIは、本当は「どこを見ればいいか」をすでに知っているのに、毎回律儀に全部読み直しているとしたらどうでしょうか。 長文コンテキストを扱うモデルは、デコードのたびに巨大なKVキャッシュ全体をスキャンします。実際にAttentionが向くのはごく一部のトークンだけなのに、既存のスパースAttention手法はそれをステップごとに探索し直す必要があり、探索自体がコストになっていました。 KAIST AIとGoogle DeepMindの研究チームは発想を転換し、「モデル自身に、今どこを見ているかを言葉で宣言させればいい」と考えました。これが「Declarative Attention」です。モデルはChain-of-Thoughtの中で、コンテキスト全体を見る、特定の箇所だけを見る、直近の出力だけを見るというモードを自ら宣言し、推論エンジンがそれをそのままAttentionマスクに変換します。 驚くべきことに、これは追加学習なしのゼロショットで機能しました。Gemma-4-31BとQwen-3.6-27Bでは、Attention対象トークンをそれぞれ52.0%・31.1%削減しながら、精度低下はわずか1〜3ポイントに収まっています。モデルが大きく、コンテキストが長くなるほど効果も安定し、最長のケースでは1回の応答あたり2,100万トークン分もの削減につながりました。 Language Models Can Control Their Own Attention 効率化と解釈可能性を同時に実現するアプローチとして、長期推論を行うエージェントの実運用コストを下げる鍵になりそうです。 #LLM# #Attention#

ハーネスエンジニアリングのプラクティス P12. 意味的サーキットブレーカーと「文脈ごと捨てる」リスタート 🎯 ポイント 同じエラーを3回繰り返すエージェント、見たことがありますか？「押し通す」より「教訓つき仕切り直し」の方が圧倒的に速いです。 📝 概要 単なる最大反復数ではなく、「同じエラーが二度」「二つの編集を振動」「正味の進捗なし」を意味的に検出して停止します。行き詰まったら、汚染された文脈でこね続けず、最後の正常チェックポイントへロールバックし、失敗の経緯を文脈から捨て、一行の教訓だけ携えて別アプローチで再起動します。 🔍 解説 エージェントが行き詰まったとき、最も非効率な対応は「同じ文脈でもう少し頑張る」ことです。失敗の経緯がコンテキストに蓄積すると、エージェントはそれに引きずられて同じ轍を踏みやすくなります。意味的サーキットブレーカーは、単なる反復回数制限ではなく、「進捗があるか」を実質的に判定します。振動（AをBに変えてまたAに戻す）や同一エラーの反復を検出したら、gitで最後の正常状態にロールバックし、新しい文脈で「前回はXで失敗した。別のアプローチを試す」という一行の教訓だけを持って再起動します。gitはエージェントのUndoです。 🛠 実践方法 ・エラーメッセージやテスト結果を比較し、「同じエラーが2回」「編集のAB振動」を検出するロジックをハーネスに実装します ・停止時にgit checkoutで最後のクリーンなコミットにロールバックし、汚染された文脈を破棄します ・リスタート時に「前回はXで失敗した」という一行の教訓だけを新しい文脈に持ち込みます ・サーキットブレーカーの閾値をタスクの難易度に応じて調整します（簡単なタスクは厳しく、難しいタスクは余裕を持たせる） 💼 ユースケース ・issue-to-PRエージェントが同じテスト失敗を修正できずループする場面 ・コンパイルエラーの修正で、修正→別のエラー→戻す→の繰り返しを検出する場面 ・レガシーコード改修で、アプローチの根本的な変更が必要だと判断する場面 ⚠ 落とし穴 サーキットブレーカーが敏感すぎると、あと一歩で解決するところで打ち切ってしまいます。逆に鈍感すぎると、コストを浪費するだけの無限ループになります。「進捗」の定義をタスクに合わせて調整することが重要です。また、リスタート時に教訓を正確に蒸留することも難しく、間違った教訓を持って再起動すると、別の失敗パターンに陥ることがあります。 #HarnessEngineering# #AIAgent#

🧩 「外側は裁量、内側は決定論」。プロンプトだけで手順を守らせると脆い——という課題を、Skillsと埋め込み型インタプリタを統合し、実行可能なコードで解くアプローチです。 タイトル: Building workflows for agents with Skills and Interpreter URL: 📝 概要 本記事は、再利用可能な振る舞いパッケージ「Skills」と、エージェントのハーネスと並んで動く埋め込み型TypeScriptランタイム「Interpreter」を統合したInterpreter Skillsを解説します。SKILL.mdが「いつ使うか」を、index.tsが「どう実行するか」を担い、エージェントは適用判断と入力だけを決め、モジュールが決定論的な実行を担います。 ❓ 解決する課題 エージェントは裁量的な判断は得意でも、決定論的な手順の遂行は苦手です。プロンプトだけの手順遵守は脆く、ステップを飛ばしたり順序を入れ替えたりします。300以上の項目を処理するような複雑な多段ルーチンでは、コンテキストをまたいで一貫性を保たせると「コンテキスト不安」が生じていました。 💡 方法論と提案手法 ・Skillsは段階的開示を用い、コンパクトなスキル一覧を見て関連するものだけ詳細を読み、プロンプトから分離してバージョン管理・共有可能な単位にします ・Interpreterはデフォルトでアクセスが制限され、ファイルシステム・ネットワーク・ツール・サブエージェントは明示的に公開した分だけ使えます ・スキルモジュールはサブエージェントをコードからプログラム的に生成・管理し、モデル介在のステップでなくコードから複雑なタスクグラフを編成します ・パースやフィルタ、グルーピングといったローカル操作はTypeScriptコードで表し、ツール面を絞ってモデルが扱いやすくします 🎯 ユースケース GitHubのIssue・PR・ディスカッションを取得し、項目ごとにサブエージェントで要約を作り、別のサブエージェントで分類・クラスタリングするトリアージなど、状態の多い多段ワークフローに向きます。 📊 評価と意義 ・「概ね指示に従ったか」ではなく「期待した関数を呼んだか」という具体的な問いを立てられ、必要な手順が正しい入力で実行されたかを測定できます ・モデルは一度呼び出すだけで、モジュールがワークフロー全体を決定論的に編成し、コンパクトな構造化オブジェクトを返します ・モデルは戦略的制御を保ちつつ、重要な手順はレビュー可能・テスト可能なコードで実行され、エージェントの作業をバージョン管理・テスト・コードレビューといったソフトウェア工学の実践へ移行させます #AIエージェント# #DevTools#

ハーネスエンジニアリングのプラクティス P10. 二相設計 —— 読み取り専用の探索 → 実装 🎯 ポイント 「まず理解してから書く」は人間の美徳です。エージェントにも同じ規律を、願望ではなく権限で強制しましょう。 📝 概要 まず書き込み禁止の探索フェーズを強制し、計画を出させてから実装フェーズに入ります。早すぎる編集を構造的に防ぐことで、計画の質が上がります。フェーズ境界は願望ではなくハーネスが権限で強制します。 🔍 解説 エージェントは「とりあえず書いてみる」傾向があります。コードの全体像を把握する前にファイルを編集し始め、後から「そもそもアプローチが間違っていた」と気づいて大幅な手戻りが発生する、というパターンは非常に多いです。二相設計では、最初のフェーズでファイル読み・検索・シンボル解決のみを許可し、編集ツールを無効化します。エージェントはコードベースを探索し、理解し、計画を立てることだけに集中します。計画が承認されて初めて編集権限が解放されます。これにより「思いつきで書いて壊す」リスクを構造的に排除できます。 🛠 実践方法 ・フェーズ1では編集ツールを無効化し、ファイル読み・検索・シンボル解決のみを許可するツールセットを設定します ・フェーズ1の出力として計画ファイル（plan.md）を要求し、計画の承認をフェーズ2への移行条件にします ・フェーズ境界はプロンプトのお願いではなく、ツールの権限レベルで強制します ・探索フェーズの時間・ステップ数に上限を設け、コンテキスト枯渇を防ぎます 💼 ユースケース ・issue-to-PRエージェントで、issueの分析と計画策定を読み取り専用で行い、計画承認後に実装に入る場面 ・レガシーコード改修で、まずモジュール地図化と理解を行い、その後に変更を加える場面 ・インシデント対応で、診断（読み取り・安全・自律）と是正（書き込み・ゲート付き）を分離する場面 ⚠ 落とし穴 探索フェーズが長すぎると、エージェントがコンテキストウィンドウを使い切ってしまいます。また、探索フェーズで得た知識が実装フェーズまでに陳腐化するリスクもあります（P3のTTLと組み合わせる）。フェーズ境界を「プロンプトでお願いする」だけでは不十分で、ツールの権限レベルで強制することが重要です。 #HarnessEngineering# #AIAgent#

# ADKの便利で実践的な使い方 🚀 ツールの並列実行、レスポンスサイズの最適化、レイテンシとトークンコストの削減 — ADKのTool Performanceガイドで、本番環境のスループットを最大化しましょう。 📌 タイトル：Tool Performance — ツール実行の最適化手法 🔗 URL： 🧩 概要 ADKではツールのパフォーマンスを最適化するための複数のアプローチが提供されています。読み取り専用ツールの並列実行、レスポンスサイズの削減によるトークンコスト最適化、そしてレイテンシ削減のためのベストプラクティスがあります。本番環境で高いスループットを実現するためには、これらの最適化が不可欠です。 🛠 使い方 並列実行とレスポンス最適化の例です。 まず、読み取り専用のツールを複数定義します。`get_user_profile(user_id: str)`、`get_user_orders(user_id: str)`、`get_user_preferences(user_id: str)` のように副作用のない関数を用意すると、ADKはこれらを並列に実行できます。次に、レスポンスサイズを削減するツール設計として `search_products(query: str, limit: int = 5)` を定義し、戻り値では `id`、`name`、`price` など必要なフィールドのみを返し、画像URLや説明文全文、メタデータ等は省略します。最後に `Agent` を `name="customer_service"`、`model="gemini-2.5-flash"` で作成し、`tools` リストにこれら4つの関数を渡します。 🏗 実践的な使い方 **並列実行の判断基準**: 副作用がなく、互いに依存しないツールは並列実行が安全です。LLMは複数のツールを同時に呼び出すことができ、ADKがそれらを並列に実行します。データの取得系ツール（GET相当）は並列実行の良い候補です。 並列実行に適した設計として、互いに独立した `get_weather(city: str)`、`get_news(topic: str)`、`get_stock_price(symbol: str)` のようなツールを定義します。各ツールはそれぞれ天気情報、ニュース記事、株価をdictで返すだけの読み取り専用関数です。LLMがこれら3つを同時に呼び出すと、ADKが自動的に並列で実行します。 **レスポンスサイズの最適化**: ツールの戻り値はLLMのコンテキストウィンドウを消費します。不要なフィールドの除外、データの要約、ページネーションの実装でトークンコストを大幅に削減できます。 **レイテンシ最適化のチェックリスト**: 1. キャッシュ可能な結果はキャッシュする 2. 外部API呼び出しにタイムアウトを設定する 3. 不要に大きなデータを返さない 4. 複数の小さなツールに分割して並列実行を促す 💡 ユースケース 📊 ダッシュボード用の複数データソース並列取得 🔍 検索結果のフィールド絞り込みによるトークン節約 ⚡ マイクロサービス間の並列API呼び出し 💰 大量リクエスト環境でのトークンコスト最適化 ⚠️ 注意点 - 副作用のあるツール（書き込み・削除）を並列実行すると、競合状態が発生する可能性があります。書き込み系ツールは逐次実行を推奨します。 - レスポンスを削減しすぎると、LLMが十分な情報を得られず、ユーザーへの回答品質が低下する場合があります。必要な情報は確実に含めてください。 - ツールのタイムアウトが短すぎると、正常なレスポンスも中断される可能性があります。適切なタイムアウト値を設定しましょう。 ✨ 小さな最適化の積み重ねが、本番環境での大きなパフォーマンス差を生みます。まずはレスポンスサイズの見直しから始めてみましょう！ #ADK# #AIAgent#

AIが「外部検索なし」でファクトを記憶・更新・忘却する時代が来ました。メモリをモデルに内蔵する新たなパラダイムが論文として公開されています。 タイトル: Metis: Memory Foundation Model 🔍 概要 現在のRAGなど外部メモリモジュールには、バックボーンとの分離・勾配伝播困難・推論レイテンシという3つの根本的限界があります。MetisはこれをTransformerブロック内に「ネイティブメモリ」として統合するアプローチで、Chain-of-ThoughtがLLMにネイティブに組み込まれたように、メモリも外部依存から解放しようとする研究です。 🛠 解決する課題と提案手法 2つのコアコンポーネントを導入します。ローカルメモリブロック（高密度メモリネットワークを推論ステップ間で指数移動平均更新）とハイパーメモリブロック（静的パラメータによるフォワードパスでのメモリ変換）です。4種のメモリ操作（Remember/Update/Forget/Reflect）を、バックグラウンドの勾配更新なしに順伝播計算だけで実行します。 📊 実験結果 コンテキストなし設定のMemOpsベンチマークで、Metis-27Bは24.76%を達成しました。 ・ベースライン Qwen3.5-27B（コンテキストなし）: 1.69% ・テスト時訓練 Temp-LoRA-27B: 9.70% ・パラメトリックメモリ δ-Mem: 4.38% 自社テストセットではReflect（マルチホップ推論）で93.44%、平均73.77%を達成。すべての比較手法を大幅に上回っています。 💡 実用的な意義 RAGの検索・ランキング・プリフィリングコストを回避しつつ、パラレル計算でメモリ操作を実行するため推論レイテンシを抑えられます。ポストトレーニングによるドメイン適応も可能で、コードとモデルチェックポイントはGitHub（MemTensor/Metis）とHuggingFaceで公開されています。 #LLM# #AIエージェント#

# Claude Agent SDKの便利で実践的な使い方 💬 エージェントとの会話を継続・再開・分岐させて、複雑なタスクをマルチターンで進められます。 セッション管理は、`continue`・`resume`・`fork` で会話の継続・再開・分岐を実現し、コンテキストを維持したマルチターン対話を可能にする機能です。 📌 タイトル：セッションの操作 🔗 URL： 🧩 概要 セッションにより会話の文脈が保持されます。Python は `ClaudeSDKClient`（セッション ID 自動管理）、TypeScript は `continue: true` でマルチターンを実現します。`resume` で中断したセッションを再開、`fork_session` で履歴を分岐して代替案を探索できます。 🛠 使い方 ```python # 再開 options = ClaudeAgentOptions(resume=session_id) # 分岐 options = ClaudeAgentOptions(fork_session=True) ``` 🏗 実践的な使い方 ・「認証モジュールを分析して」→「JWT 化してリファクタして」と文脈を引き継ぐマルチターン対話を構築します。 ・`error_max_turns` で終了したセッションを `resume` でより高い上限で再開し、続きから実行します。 ・`fork_session=True` で元セッション（JWT 路線）を壊さず OAuth2 路線を別ブランチで探索。2つの独立した履歴を保持します。 ・`list_sessions` / `get_session_messages` / `rename_session` でセッションピッカー UI やクリーンアップ処理を構築します。 💡 ユースケース 🔄 制限到達後のセッション再開による継続実行 🌿 fork による代替アプローチの並行探索 🗂 セッション一覧 UI の構築 ⚠️ 注意点 セッションは `~/.claude/projects//.jsonl` に保存されます。ホスト間での再開には `cwd` の一致が必要です。サブエージェントのトランスクリプトはメイン会話と独立して永続化されます。 #ClaudeAgentSDK# #AI#

# AIエージェントをエンタープライズシステムに組み込む意思決定ポイント # シングル vs マルチエージェント｜Single vs Multi-Agent 🎯 ポイント 「マルチエージェントの方が賢そう」という理由だけで複数エージェント構成を選んでいませんか？ マルチエージェントは万能ではなく、オーケストレーションの複雑性・レイテンシ・コストを必ず伴います。シングルで済むならシングルが最善です。分割の判断基準は「ツール数」「権限分離」「並列実行の効果」の3つです🔑 📋 概要 1つのエージェントで完結させるか、複数の専門エージェントに分割するかは、タスクの複雑さ・ツール数・権限分離の要件・コスト感度によって決まります。シングルエージェントはタスクが単一ドメインに収まり、ツール数が30以下で、レイテンシ要件が厳しい場面で力を発揮します。SlackボットでのFAQ回答やSalesforceの単一レコード検索・更新のように、スコープが明確なタスクはシングルで十分です。マルチエージェントが活きるのは、専門領域が複数にまたがり、法務・経理・人事のように役割ごとに異なる権限とデータアクセスが必要な場面です📊 🔍 意思決定のポイント 判断は以下の順で行います： ツール数は30以下か？ → 30以下で精度に問題なければシングルで十分 権限分離が必要か？ → 法務データと営業データを同一エージェントに持たせると情報漏洩リスク 並列実行の効果は？ → 3つ以上のSaaSを同時に調査するなら並列化の恩恵が大きい レイテンシ要件は？ → ハンドオフのオーバーヘッド（目安1〜3秒/回）を許容できるか コスト制約は？ → オーケストレーション分のLLM呼び出しが追加で発生する 重要なのは、ツール数50超を1つのエージェントに持たせるとツール選択精度が60%以下に低下する傾向があるという経験則です。このラインを超えたらtool RAGで動的フィルタするか、エージェントを分割しましょう⚡ 💡 要点と詳細 段階的拡張が最も安全なアプローチです： 初期はシングルエージェントで構築し、ツール数やタスク複雑性の増加に応じて専門エージェントを分離します。分離の判断基準は「ツール選択の精度低下」と「権限分離の要件」です。 マルチエージェント構成のパターン： - ルーター＋専門エージェント：スーパーバイザがユーザーの意図を判定し、適切な専門エージェントにルーティング。各専門エージェントはシングルとして動作します - 並列実行：Workdayの人事データ、Salesforceの商談データ、Jiraの開発進捗を並列に取得して統合する経営ダッシュボード生成 - エージェントごとの最適モデル選択：高精度が必要な分析には大型モデル、定型処理には高速・低コストモデルを使い分け ServiceNowのインシデント対応では、一次分類エージェント（シングル・高速）が受付し、深堀り調査が必要な場合にインフラ調査エージェント・ログ分析エージェントを並列起動する構成が効果的です🔄 ⚖️ トレードオフ 「とりあえずマルチ」で始めると、実際にはシングルで十分なタスクにオーケストレーションの複雑性を持ち込み、デバッグ困難・コスト増大・レイテンシ悪化を招きます。マルチエージェントの月間LLMコストはシングルの2〜5倍になることも珍しくありません😰 一方、エージェント間の文脈共有を軽視するのも致命的です。ハンドオフ時にコンテキストが失われると、ユーザーが同じ情報を繰り返し伝える羽目になります。共有メモリの設計が不可欠です。 権限分離なしのマルチエージェントも意味がありません。エージェントを分割しても全員が同じ権限で動作していれば、分割の安全性メリットはゼロです。エージェント単位で最小権限を設定してください⚠️ 🛠️ ユースケース 社内FAQ・ナレッジ検索：ツール数10以下、単一ドメイン、レイテンシ重視。シングルエージェントが最適解。無理にマルチにする必要はありません📚 経営ダッシュボード生成：Workday・Salesforce・Jira・Slackの4システムを横断。各システムの専門エージェントが並列にデータを取得し、集約エージェントが統合レポートを生成。ツール数50超・権限分離必要・並列効果大でマルチエージェントの適用が明確です🛒 開発チーム支援：初期はシングルエージェント（GitHub + Jira連携、ツール数15）で開始。半年後にセキュリティスキャン・パフォーマンス分析・ドキュメント生成が追加されツール数40超に。ツール選択精度の低下を検知し、セキュリティ専門エージェントを分離する段階的拡張パターンです🔧 実践のコツ：シングルで始めて、ツール選択精度のモニタリング（正しいツールが選ばれた割合）を計測してください。精度が80%を切ったら分割の検討タイミングです💪 #AIエージェント# #エンタープライズアーキテクチャ#

良い写真ですね キオクシア、メモリプーリングのCXLモジュールサンプル出荷 【ニュース】キオクシア、近々CXLモジュールのサンプル出荷を開始か、NVIDIA CMXとの強固な関係を再確認 AIワークロードがますます多くのメモリを必要とするにつれ、DRAMの物理的な容量の限界がボトルネックになりつつある。EE Times Japanによると、日本のNAND大手は9月3日のブリーフィングで、同社のCXLメモリモジュールが従来の方式と比較してレイテンシを90%以上削減しながら使用可能なメモリ容量を拡大する方法を詳しく説明した。 EE Times Japanによると、キオクシアは間もなくCXLメモリモジュールのサンプル出荷を開始する予定だという。 キオクシアのメモリ事業部でメモリ応用技術責任者を務める松寺勝樹氏の言葉を引用し、同レポートはさらに、シミュレーションの結果、DRAMの3分の1をCXLメモリモジュールに置き換えることで、性能低下を5%未満に抑えられることが示されたと指摘している。また、同じコストでDRAMの一部をCXLメモリモジュールに置き換えることで、容量を2倍にしながら性能を1.3倍に向上させることも可能だと付け加えている。 CXLがギャップを埋める方法 報告書が指摘するように、AIはDRAMの需要を大きく押し上げているが、DRAMの容量には限りがあるため、データ量の増加に伴いシステム内でメモリを拡張することは困難である。NANDフラッシュははるかに大きな容量を提供するが、レイテンシが高く書き込み耐久性が低いというトレードオフがあり、メインメモリにおけるDRAMの直接的な代替品としては不向きである。 松寺氏によると、実際のアクセスパターンは80対20の比率で、メモリアクセスの約80%はデータのわずか20%にアクセスし、残りのデータへのアクセス頻度ははるかに低いという。キオクシアのアプローチはこのギャップを利用し、80%のデータをフラッシュメモリに保存する。フラッシュメモリはDRAMと同様にメモリとして直接アクセスできるため、パフォーマンスを犠牲にすることなく容量の制約を緩和できる。 しかし、フラッシュメモリ特有のレイテンシーは依然として課題だった。このギャップを埋めるため、キオクシアはレイテンシー低減機能を備えた専用コントローラを開発した。EE Times Japanによると、XL-FLASHと組み合わせたCXLメモリモジュールは、従来の方式と比較してレイテンシーを90%以上削減できるという。 キオクシアはCXL以外にも、主力製品であるBiCS Flashのロードマップを更新した。同社は7月から岩手県北上工場で第10世代BiCS FLASH 3Dフラッシュメモリの量産を開始し、同時に1Tb TLC製品のサンプル出荷も開始した。EE Times Japanによると、新世代は第8世代と比較してビット密度が59%向上、読み出し電力効率が40%向上、書き込み電力効率が30%向上している。 CMXとNVIDIAのコラボレーションに注目 特筆すべきは、BigGo Financeが、キオクシアとNVIDIAがCMX（Context Memory Storage）に関して協力していると報じている点である。CMXは、NVIDIAが3月に発表した新しいストレージ層で、BlueField-4データ処理ユニットを中心に構築されており、長文コンテキストの会話型およびエージェント型AI推論のためのGPUメモリを拡張することを目的としている。 その協力関係は既に成果を上げており、キオクシアは7月にCM10シリーズを発表した。これは、第10世代BiCS FLASH TLCを搭載し、NVIDIA CMXアーキテクチャをサポートするように設計された最新のエンタープライズ向けSSDで、前世代に比べてパフォーマンスと電力効率が大幅に向上している。 キオクシア初のPCIe 6.0エンタープライズSSDであるCM10シリーズは、直接冷却プレート式液冷にも対応しており、次世代AIインフラストラクチャの冷却において、より高い柔軟性と効率性を提供すると、同レポートは付け加えている。 報道によると、SSD事業部技術企画部長の浜田誠氏は、市場の巨大な潜在力を考えると競争は避けられないとしながらも、キオクシアはNVIDIAと緊密に連携し、主要幹部と定期的に連絡を取り合っていると述べた。「我々は後れを取っているとは感じていない」と浜田氏は述べ、キオクシアはAI PCや物理AIにおける新たなストレージニーズにも注目していると、同報道は示唆している。 SeDailyが指摘するように、サムスンもこの市場における重要なプレーヤーとなる可能性がある。韓国のメモリ大手であるサムスンは、NVIDIAの次世代ストレージアーキテクチャであるCMX（今年後半に発売予定）に後押しされ、V9 NANDの生産能力拡大を加速させていると報じられている。 SeDailyによると、NVIDIAのCMXは576個のSSDを搭載し、総容量は9,600TBに達する一方、同アーキテクチャ向けのNANDフラッシュメモリの需要は、今年の3,500万TBから来年には1億TB以上に急増すると予測されている。サムスンのNANDフラッシュメモリの生産量は今年約2億5,000万TBに達すると見込まれており、同社は巨大な生産能力を駆使して、成長著しいCMX市場でより大きなシェアを獲得しようとしている、と同レポートは付け加えている。