🧭 TL;DR: モデルが賢くなったのに、指示だけ旧モデル仕様のままだと逆に足を引っ張ります。OpenAIがGPT-6 Astra移行時のスキル・プロンプト見直し方をまとめました。 タイトル: Rethinking skills and prompts for GPT-6 Astra URL: 📌 ポイント 📝 スキルの説明は発動条件を絞って簡潔に書く 📂 複雑なスキルは最初から全文脈を読ませず段階的に開示する 🎯 過剰に具体的な指示はむしろ精度を下げることがある 📄 AGENTS.mdは一律の必読リストより文脈に応じた参照にする ⚖️ 旧モデル向けの行動制限がAstraでは過剰な自己制限になりうる 🛑 完了条件・探索範囲・停止条件を事前に明示しないと早く止まりがち モデルが進化したら指示はむしろ削る、という逆説的だけど実践的な学びが詰まっています。 #AIエージェント# #プロンプトエンジニアリング#

動画生成モデルは「もっともらしい動画」を作れても、「正しい確率で将来を分布できる」かは別問題です。 タイトル: PAWBench: How Far Are We from Probabilistically Aligned World Modeling? URL: 🎯 概要 コインを50回投げたとき表と裏が約50%ずつ出るように、動画生成モデルも「ありうる将来の正しい確率分布」を再現できなければ真のワールドモデルとは言えません。PAWBenchはこの「確率的整合性」を評価する初の体系的ベンチマークで、50シナリオ・11モデルを評価しました。 🔍 解決する課題 従来の動画評価はFIDやFVDなどの知覚品質や多様性に焦点を当ててきましたが、「各結果が正しい頻度で生成されるか（較正）」と「すべてのありうる結果を網羅できるか（網羅性）」を同時に測る指標がありませんでした。 ⚙️ 評価手法 PAWEvalはK=50回の動画生成をGemini 3.5 Flashで終端結果に変換し、全変動距離（TVD）と有効サポート回収率で評価します。投擲・回転・衝突・材料遷移など8種類の物理メカニズムを対象としています。 📊 主要結果 最良モデルのCosmos 3 Super I2VでもTVD 20.5（完全整合=0）に留まります。全モデルの平均TVDは31.2で、有限サンプルで予想される偶然のばらつき（8.33）を大幅に上回ります。「確率精度・広い網羅性・採点信頼性」を同時に達成したモデルは1つもありませんでした。 ⚡ 介入実験の教訓 プロンプトエンジニアリング・結合ノイズサンプリング・LoRA微調整の3つを試しましたが、いずれも部分的な改善にとどまり根本的なギャップは解消されませんでした。モデルは物理的因果介入には過少反応し、非因果的な視覚・テキスト手がかりには過剰反応する傾向があります。 動画生成をロボティクス・自動運転・物理シミュレーションに応用しようとする研究にとって、確率的整合性はこれから欠かせない評価軸になります。 #動画生成# #ワールドモデル#

マネジメント色でありながら、どうやって技術力を保っていくか、という話。 ・EMにとって技術的習熟もはやオプションではなく必須のスキル ・技術的習熟とは、チーム内で最も優れたプログラマーになることを意味するではない ・システム構造や技術的な課題を的確に理解する能力のこと ・マネージャーが技術を理解していると、エンジニアは自分たちの状況や苦労を正しく代弁してくれると感じて強い信頼を寄せる ・技術的な知識があれば、現場のエンジニアの作業を中断させて質問することなく、マネージャー単独で迅速に意思決定ができる ・また、技術詳細をマネージャー自身が把握しておくことで、経営層などのステークホルダーに対する報告やフィードバックのサイクルを短縮できる ・他に、チームの業務に必要な技術的要件を正確に把握できるようになるため、採用活動においてもより優秀なエンジニアを見極めやすくなる ・マネージャーが技術力を維持し向上させるための実践的なアプローチとしては、主に4つの方法が存在する ・第一の方法は、AIに対する適切な指示出しであるプロンプトエンジニアリングのスキルを抑えること ・第二の方法は、現場のエンジニアと一緒に具体的なタスクに取り組みながら学ぶこと ・この共同作業はエンジニアの本来の業務を圧迫しないよう、ロードマップに影響しない優先度の低いタスクを選んで実施すると良い ・一緒に作業をする際は、評価目的ではなくマネージャー自身の学習目的であることを率直に伝えておく（負担になるから） ・第三の方法は、チームの業務に関連する特定の技術ドメインをひとつ選び、その分野の専門知識を計画的に身につけること ・第四の方法は、システムの将来性や保守性を大きく左右する重要なアーキテクチャ設計のレビューに積極的に参加すること ・技術的習熟は一度で終わるものではない ・日々の小さな積み重ねによる継続的な自己投資によるもの

ハーネスエンジニアリングのアンチパターン AP10. 観測なきブラックボックス（The Unobservable Black Box） 🎯 ポイント 失敗の原因がモデルか、プロンプトか、ツールか、コンテキストか、環境か——誰にも切り分けられない。改善が迷信と勘で行われるハーネスは、改善不能です。 ❗ 発生する課題 失敗をサブシステムに帰属できないため、何を直すべきかが分かりません。改善が迷信と勘で行われ、ハーネスの振り返りループが回らなくなります。単一指標だけを追う「指標モノカルチャー」と結びつくと、測定されていない品質が静かに犠牲になります。 🔍 メカニズムと症状 可観測性は地味なインフラ作業であり、エージェントは「だいたい動く」ため、このアンチパターンは後回しにされがちです。しかし、サブシステムに失敗を帰属できなければ、振り返りループが回せず、ハーネスは改善不能になります。さらに、単一指標（例：成功率だけ）を追うと、測られていない美徳（レビュー時間・リグレッション率・コードの保守性）が静かに犠牲になる「指標モノカルチャー」が発生します。症状としては、「なぜ失敗したか分からない」が頻発する、改善施策が「プロンプトをいじる」一辺倒になる、モデルの問題かハーネスの問題か区別がつかない、成功率は上がっているのにレビュアーの不満が増える、といった現象が見られます。 📋 シナリオ ・エージェントがタスクに失敗するが、原因がモデルの推論ミスか、コンテキストの不足か、ツールのバグか、環境の問題か誰にも分からない。チームは「プロンプトをもう少し詳しくしよう」と対症療法を繰り返す。 ・成功率を唯一の指標として追跡。成功率は80%に向上したが、成功した案件のレビュー時間が3倍に膨れ上がっていることに気づかない。 ・モデルをアップグレードしたが性能が変わらない。原因がモデルの問題なのか、ハーネスの足場が制約しているのか（AP3）切り分けられず、投資判断が迷信になる。 🛡 回避方法 ・決定・ツール呼び出し・コンテキスト変遷をトレースし、7サブシステム（知覚・行為・フィードバック・制御・記憶・ガードレール・インターフェース）に帰属可能化します ・単一指標でなく束で測定します（成功率・介入率・手戻り率・リグレッション率・コスト・レビュー時間・確信度の較正） ・モデルを固定してハーネスの変更をA/Bテストし、改善をハーネスに帰属させます ・ハーネスの可観測性を「地味だが不可欠なインフラ」として投資し、改善ループの基盤を整えてください #HarnessEngineering# #AIAgent#

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

ハーネスエンジニアリングのアンチパターン AP7. 決定性の取り違え（The Misplaced Determinism Boundary） 🎯 ポイント テスト実行をLLMの善意に委ね、端ケースの判断を硬いルールに押し込む。境界を取り違えると、信頼性と適応性を同時に失います。 ❗ 発生する課題 確率的な要素を決定的であるべき場所に置くと信頼性が漏れ、決定的なルールを判断が要る場所に置くと適応性を失います。結果として、簡単なタスクで不安定になるか、複雑なタスクで硬直するか、あるいはその両方が同時に起きます。 🔍 メカニズムと症状 この取り違えには二つの形態があります。形態Aは「LLMの判断が要る長いテールを硬いルールに押し込む」パターンで、ルールは予測可能なため魅力的に見えますが、端ケースに遭遇すると脆く壊れます。形態Bは「決定的であるべき処理（テスト実行、ゲート判定、リトライ）をLLMの善意に委ねる」パターンで、モデルに任せれば実装が楽に見えますが、100回に1回はテストを忘れるという不安定さを生みます。症状としては、形態Aでは「想定外のケースでルールが破綻」「新しいパターンのたびにルール追加が必要」、形態Bでは「テストの実行忘れ」「ゲートのスキップ」「時々なぜか動かない」が見られます。 📋 シナリオ ・形態A：「import文の変更は必ずファイル先頭に」という硬いルールを設定。circular importの解消が必要なケースでルールが邪魔をし、エージェントが行き詰まる。 ・形態B：「テストを必ず実行すること」をプロンプトに記載するだけで、ハーネスが強制しない。エージェントは95%の確率でテストを実行するが、残り5%でテスト未実行のまま完了を宣言する。 ・両方同時：コードモッドの大部分はASTベースの決定的変換で処理できるのに、全てをLLMに任せている（形態B）。一方、LLMの判断が必要な端ケースには「この場合はスキップ」という硬いルールを適用（形態A）。両方が間違っている。 🛡 回避方法 ・ハーネスの全処理を「判断が要る」と「判断不要で決定的に実行可能」に分類し、境界を明示します ・テスト実行・lint・ビルド・ゲート判定は決定的コードで強制し、「お願い」しません ・LLMは本当に判断が必要な部分（原因分析・方針決定・コード生成）に限定して使います ・モデルの進化に合わせて境界を定期的に見直し、適切に移動させてください #HarnessEngineering# #AIAgent#

ハーネスエンジニアリングのプラクティス P4. サブエージェントは「蒸留器」として契約する 🎯 ポイント サブエージェントが50ファイルの生ログを親に返したら、親のコンテキストは即死します。返すべきは「議事録」ではなく「結論」です。 📝 概要 探索用サブエージェントの契約を「結論を返す、議事録は返さない」と定義します。50ファイル探索して5行の所見を返す。これは礼儀ではなく、文脈階層のメモリ管理規律です。 🔍 解説 サブエージェントを使う主な目的は、親エージェントのコンテキストウィンドウを守ることです。しかし、サブエージェントが生の探索結果をそのまま返してしまうと、その目的は完全に失われます。サブエージェントは「蒸留器」として機能すべきです。大量の情報を読み込み、本質だけを凝縮して返す。この契約を明示的にプロンプトで定義し、返答のフォーマットも制約することで、文脈階層全体の効率が保たれます。安価なモデルで広く探索し、高価なモデルで深く判断する、というトークン経済の原則とも合致します。 🛠 実践方法 ・サブエージェントのプロンプトに「結論を返す、議事録は返さない」と明記し、返答フォーマット（行数上限・構造）を制約します ・探索タスクには安価なモデルを使い、親エージェントの判断には高価なモデルを使うトークン経済を設計します ・サブエージェントの返答サイズを監視し、閾値を超えた場合は再蒸留を要求するガードを設けます ・蒸留の粒度をタスクに応じて調整します（分類タスクなら3行、分析タスクなら10行など） 💼 ユースケース ・大規模コードベースの調査で、複数のサブエージェントにファイル群を分担探索させ、各々が要約のみ返す場面 ・マイグレーションで、各ユニットの状況を調査するサブエージェントが「移行可／要手動対応／不明」の3分類だけを返す場面 ・インシデント対応で、ログ・メトリクス・トレースを別々のサブエージェントが調査し、相関する異常の要約だけを返す場面 ⚠ 落とし穴 サブエージェントの蒸留品質が低いと、重要な情報が失われるリスクがあります。「結論だけ返せ」と指示しても、何が結論に値するかの判断はモデルの能力に依存します。また、蒸留の過程で文脈が失われすぎると、親エージェントが誤った判断をする可能性もあります。蒸留の粒度は、タスクの性質に応じて調整が必要です。 #HarnessEngineering# #AIAgent#

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

🔄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エージェントが壊れたとき、何万件ものトレースを人手でさかのぼる時代は終わりを迎えつつあります。 🔍 エージェントが大規模に動き始めると、問題の見つけ方が根本から変わります。数行のログを追うのではなく、数千万件のトレースの中から異常の糸口を引き出す必要が生まれる。それを人の目でこなすのは、どう考えても持続しません。LangSmith Engineはそのギャップを埋めるために2025年5月にローンチし、以来6000万件超のトレースをスキャンして2万件以上の課題を検出し、数万時間分のエンジニアリング工数を節約してきました。 💡 今回のアップデートで、Engineの中核である課題検出能力が大きく前進しました。内部ベンチマークでissue検出精度が2倍以上、業界標準ベンチマークでissue修正精度が25%向上しています。Engineは証拠・インシデントタイムライン・根本原因分析を伴う診断を行い、プロンプトまたはコード変更の修正案と即デプロイ可能なPRを自動生成します。さらに修正後の再発監視まで担い、人が介在する部分を最小限に抑えます。 🏗️ 今回あわせて発表された新機能も実用性が高いです。エンタープライズ顧客は自社VPC内にEngineをデプロイするセルフホスト構成が選択可能になり、Slack通知でエンジニアへのアラートが届き、Linear連携でチケットが自動作成されます。コスト面ではスキャンするトレース数を絞るReduced Analysisモードが加わり、古い未対応issueを自動クローズするStale issue管理も整備されました。 ロードマップでは、既存データセットへの自動修正検証と、プロダクショントレースから評価データセットをEngine自身が生成する機能が控えています。「発見→修正→検証→監視」の閉ループが完成に近づいています。 New in LangSmith Engine: >2x better issue detection #LangSmith# #AIAgents#