Sesame blog

「コードを書くだけ」の時代は終わった：AI コーディングエージェントの非開発応用と Antigravity Python SDK の本質

Sun, 23 Aug 2026 05:15:00 +0000

個人用メモ・備忘録

日々の開発・インフラ検証の備忘録として残している個人ノートです。手元環境での動作ログをもとにまとめています。環境差異等もあるため、参考にされる場合はご自身の環境で検証の上ご活用ください。

はじめに

「AI コーディングエージェント（Antigravity、Claude Code、SWE-agent 等）は、エンジニアがアプリケーションのコードを書くためのツールである」──多くの人がこのように捉えています。

しかし、Antigravity が提供するインターフェース群を見渡したとき、ひとつの大きな疑問が浮かびます。

「VS Code 拡張機能や CLI があるのに、なぜ公式の Python SDK（google-antigravity）が提供されているのか？」

人間がチャット画面やエディタで対話するだけなら、Python ライブラリとしてエージェントを操作する SDK は本来必要ありません。この問いの答えこそが、AI コーディングエージェントという技術の本質が「単なるプログラミング支援」を遥かに超えた領域にあること を物語っています。

本記事では、コーディングエージェントが持つ真のアーキテクチャ的本質、Python SDK が存在する必然性、そして SRE・データ分析・セキュリティ監査・リサーチといった「開発用途以外（Non-Coding Ops）」への実務応用パターンを解説します。

なぜ「コーディング」から始まったのか？──閉じたループの必然性

AI エージェント技術が、事務作業や一般的なチャットボットではなく「ソフトウェア開発（Coding）」の領域で最も早く実用レベルに達したのは偶然ではありません。

自律エージェントがタスクを完遂するためには、以下の 3 つの要素が不可欠です。

決定論的なフィードバック環境:
- コードを実行した結果、構文エラーやテスト落ちがシェル標準出力・エラー（stderr）として明確に返ってくる。
自己修復可能な閉ループ（Closed Loop）:
- エラーログを読み取り、原因となったファイルを修正し、再度テストを走らせて合否を機械的に判定できる。
豊富なコンテキスト操作インターフェース:
- ripgrep や git などの UNIX コマンドを通じて、必要な情報だけを外科手術のように探索・収集できる。

【エージェントにとっての「ソフトウェア開発」という領域】
指示 ➔ 探索（rg, fd） ➔ 修正（edit） ➔ 検証（pytest / npm test） ➔ 合否判定 ➔ 完了
 ↑ │
 └─────────────── エラー出力で自律修正 ───────────────┘

つまり、「コーディング」はエージェントにとって 最も検証が容易で、自己完結したフィードバックループを回しやすい理想的な実験場（Sandbox）だった に過ぎません。

エージェントが内部で獲得した「ファイルシステムを探索し、コマンドを実行し、出力を解析し、外部ツール（MCP）を叩き、ゴールに達するまで自律的に試行錯誤する」という能力は、本質的に あらゆるコンピュータ作業に応用可能な「汎用自律オペレータ」そのもの です。

Antigravity Python SDK が存在する真の理由

Antigravity には、VS Code 拡張機能、デスクトップアプリ（Antigravity 2.0）、ターミナル CLI（agy）のほかに、公式の Python SDK（google-antigravity） が用意されています。

flowchart TD
 subgraph Core ["Antigravity Agent Runtime（推論・ツール・自律ループ）"]
 Gemini["Gemini 基盤モデル"]
 Tools["ツール群（ファイル編集 / シェル実行 / MCP / 検索）"]
 Loop["自己検証・計画推論ループ"]
 Gemini --- Tools --- Loop
 end

 SurfaceGUI["1. GUI (VS Code 拡張機能 / 2.0)<br>➔ 人間が手元で対話・レビュー"]
 SurfaceCLI["2. CLI (agy)<br>➔ ターミナルから人間がタスク委譲"]
 SurfaceSDK["3. Python SDK (google-antigravity)<br>➔ プログラム・バッチ・他システムへ自律コアを組み込み"]

 Core --> SurfaceGUI
 Core --> SurfaceCLI
 Core --> SurfaceSDK

「人間対面（Chat）」から「システム組み込み（Headless Runtime）」への飛躍

GUI や CLI は、すべて「人間のオペレータ」が画面の前に座って指示を与えることを前提としています。

一方、Python SDK は 「エージェントの自律頭脳を、1 つの非同期関数・モジュールとして既存のプログラムや自動化パイプラインに組み込むこと」 を目的としています。

Cron / Airflow などのワークフロー:
- 定期的に起動し、障害の予兆検知やレポート生成を完全無人で実行。
FastAPI / バックエンド API 連携:
- ユーザーからの複雑な非構造化リクエストを受け取り、バックグラウンドでエージェントが複数ツールを駆使して調査・集計した結果をレスポンス。
CI/CD パイプライン & セキュリティゲート:
- プルリクエスト作成時に、コードの文法だけでなく「アーキテクチャ整合性」や「最新 CVE 脆弱性情報」を自律調査して自動コメント。

Python SDK は、エージェントを「開発者のアシスタント」から 「24 時間 365 日稼働する自律デジタルワーカーのエンジン」 へと昇華させるための窓口です。

開発用途を超えた 5 つの実務ユースケース

「ファイル操作」「シェル実行」「Web 検索」「MCP 外部連携」を組み合わせることで、開発以外の領域において以下のような高度な自動化が実現します。

領域	従来の課題（静的スクリプトや人間作業）	AI エージェントによる自律解決（Python SDK）
① DataOps / レポート生成	データ形式が変わるたびにスクリプト修正が必要。定性的なインサイト要約は人間が手書き。	データを読み取り、自ら可視化 Python スクリプトを生成・実行してグラフを出力し、洞察レポートを Markdown 化。
② SRE / インシデント調査	アラート発報後、エンジニアが手作業で複数ログやメトリクスを横断調査し初動が遅れる。	アラートをフックして自律起動。ログ調査、メトリクス照会、原因の特定と暫定復旧コマンドの提案までを自動完遂。
③ SecOps / コンプライアンス	静的ルール（Linter）では文脈や最新のゼロデイ脆弱性（CVE）に対応できない。	設定ファイルや IaC を読み、Web 検索で最新の脆弱性データベースと照合して影響範囲を判定・パッチ作成。
④ Docs as Code / 品質管理	ドキュメントのリンク切れ、表記揺れ、コード例の動作検証が手動で形骸化。	ドキュメント内のコードを実際にテスト環境で実行・検証し、壊れたサンプルコードやリンクを自律修正。
⑤ Research & ファクトチェック	Web 検索結果を人間が何時間もかけて目視確認・精査・比較表作成。	Web 検索ツールと MCP を駆使して一次情報ソースを多角的に収集し、ファクトチェック済みの要約を作成。

ユースケース詳細

1. DataOps：アドホック分析とビジュアルレポートの完全自動化

従来のデータ分析スクリプトは、想定外のカラム変更や欠損値で即座にエラー停止します。エージェントは、エラーが発生しても「エラー出力を読み取って Pandas の処理を自己修正し、再実行する」という自律ループを持つため、未知のデータセットに対しても確実にグラフ描画とインサイト抽出を完走させます。

2. SRE / インフラ運用：障害の自律トリアージ

PagerDuty や Datadog のアラート通知をトリガーに Python SDK 経由でエージェントを起動します。エージェントは Kubernetes クラスタやサーバーに接続し、kubectl logs や journalctl を叩いて直近のエラーログを特定。Prometheus のメトリクスと突合し、「どのデプロイが原因か」を突き止めて Slack に詳細なインシデント初動レポートを投稿します。

Python SDK による実装例：SRE 障害調査エージェント

以下は、Antigravity Python SDK（google-antigravity）を用いて、障害ログを自律調査し、サマリーレポートを生成するスクリプトの例です。

import asyncio
import sys
from google.antigravity import Agent, LocalAgentConfig, CapabilitiesConfig

async def investigate_incident(log_dir: str, incident_id: str):
 """
 障害ログディレクトリを自律調査し、原因特定と暫定復旧策をまとめたレポートを出力する
 """
 # ツール実行権限（ファイル読み取り・シェル実行）を安全に構成
 config = LocalAgentConfig(
 system_instructions=(
 "あなたは高度な SRE 診断エージェントです。"
 "提供されたログディレクトリ内のファイルを調査し、エラーログの抽出、"
 "時系列での影響分析、および根本原因の仮説を立てて Markdown レポートを作成してください。"
 ),
 # 安全のため、書き込み権限やコマンド実行を明示的に有効化
 capabilities=CapabilitiesConfig(),
 )

 prompt = f"""
 インシデント ID: {incident_id} の調査を開始してください。
 対象ログパス: {log_dir}
 
 1. rg コマンド等を用いて、直近 1 時間の ERROR / FATAL ログを抽出してください。
 2. エラー発生前後の設定変更や例外スタックトレースを特定してください。
 3. 根本原因の要約と、推奨される暫定対応手順をレポートとしてまとめてください。
 """

 print(f"[*] インシデント {incident_id} の自律調査を開始します...\n")

 async with Agent(config) as agent:
 response = await agent.chat(prompt)

 # エージェントの回答トークンをストリーミング表示
 async for token in response:
 sys.stdout.write(token)
 sys.stdout.flush()
 print("\n\n[*] 調査が完了しました。")

if __name__ == "__main__":
 # 実行例
 asyncio.run(investigate_incident(log_dir="/var/log/app", incident_id="INC-20260823-01"))

エンタープライズ導入における安全設計（Safety by Default）

業務システムや自動化パイプラインにエージェントを組み込む際、最大の懸念となるのは「予期しないコマンド実行やデータ破壊」です。Antigravity Python SDK は以下の多層防御アーキテクチャを備えています。

Read-only デフォルト原則:
- capabilities=CapabilitiesConfig() を明示的に設定しない限り、ファイル編集やシェル実行は遮断され、探索・読み取り専用で動作します。
サンドボックス隔離:
- コマンド実行は隔離されたサンドボックス環境内で行われ、ホスト OS や不要なネットワークアクセスへの影響を防止します。
可観測性（Streaming Thoughts / ToolCalls）:
- response.thoughts（思考ログ）や response.tool_calls（実行されたツール名と引数）をリアルタイムにプログラム側でフック・監査ログに記録できます。

運用で AI エージェントを活用する 3 つのアプローチと使い分け

実務の運用現場で AI エージェントを活用するアプローチは、大きく以下の 3 つの方式（パターン） に整理できます。

方式	概要・代表例	メリット	デメリット・制約	最適な利用シーン
① コーディングエージェント流用型（Zero-code Ops）	`agy` / Claude Code / Cursor を運用サーバーや端末で直接起動し、自然言語で指示	・開発コスト 0（即座に使える）・高いアドホック柔軟性（`kubectl`, `ssh`, `docker`, `jq` 等の全ツールを AI がその場で組み合わせる）	・無人の定常自動化には向かない（人間が CLI を叩く必要がある）・権限が広すぎるため破壊的コマンドの安全管理が必要	アドホックな障害調査、ワンオフのログ解析、環境構築、緊急トラブルシュート
② プロコード自作型（SDK / Pipeline 組み込み）	Antigravity Python SDK や LangGraph 等で、専用の運用スクリプト・サービスを構築	・完全無人・イベント駆動（Webhook / Slack）・厳格な権限管理 & 監査ログ（実行可能コマンドをホワイトリスト化）	・コードの実装・保守コストがかかる・想定外の事態（Ad-hoc）への柔軟性はツールの設計範囲に限定される	定常監視バッチ、インシデント自動一次トリアージ、CI/CD セキュリティゲート
③ 専用エージェント型（Turnkey Agents）	OpenClaw / K8sGPT / HolmesGPT などの特定用途完成品エージェント	・UI やチャット連携が完成済み・特定ドメイン（Slack 連携、K8s 診断等）に特化したチューニング	・製品の枠組みを超える作業ができない・社内独自システムや特殊なログ形式への適応が難しい	個人・チームの日常雑務代行（Slack 経由）、標準的な K8s クラスタの診断

各アプローチの背景と実例

1. コーディングエージェント流用型：なぜ「非公式」な使い方が最も柔軟なのか？

一見すると「開発用ツールを無理に使っている」ように思えるコーディングエージェント（agy や Claude Code）の運用流用ですが、実務上は 柔軟性が高く、立ち上げの手間が不要な即効性のあるアプローチ です。

プロコードでエージェントを自作する場合、「この API を叩く関数」「このログを取得するツール」を人間が 1 つずつ Python で定義してあげる必要があります。一方、コーディングエージェントは 「すでに完全なシェル実行環境と自己修復ループを持っている」 ため、サーバー上にある kubectl、grep、systemctl、aws CLI などを、その場の状況に応じて AI 自身が勝手に組み合わせて目的を達成します。

2. プロコード自作型：Antigravity Python SDK や LangGraph による統制

エンタープライズの運用では、エージェントに広範なシェル権限をそのまま渡すことはセキュリティ上許容されません。
そのため、LangChain 社が提供する LangGraph や、Google の Antigravity Python SDK を用いて、「許可されたクエリのみを実行し、結果を整形して Slack に投稿する」といった 権限境界（Guardrails）をプロコードで厳格に定義したパイプライン が構築されます。

3. 専用エージェント型：OpenClaw や CNCF プロジェクトの台頭

特定業務に特化した完成品エージェント（Turnkey Agents）も急速に普及しています。

パーソナル自動化（OpenClaw）: Peter Steinberger 氏によって開発されたオープンソースのセルフホスト型エージェント。WhatsApp、Telegram、Slack などのチャットアプリから指示を送り、裏でブラウザ操作やファイル操作を代行させるパーソナル執事として広く活用されています。
Kubernetes 診断（K8sGPT）: CNCF Sandbox プロジェクトとして、クラスタ内のエラーや設定ミスを自動スキャンして平易な自然言語で解説・トリアージする診断特化ツール。
フルスタック SRE 調査（HolmesGPT）: K8s クラスタだけでなく、VM、クラウド API、データベースを横断してインシデント調査を行う自律型 SRE エージェント。

実務での判断基準（Decision Flow）

flowchart TD
 Start["運用の自動化・効率化をしたい"] --> Q1{"定常的な無人実行が必要か？<br>（Webhook/Slack連携/定期Cron）"}
 
 Q1 -- "No（人間がその場で調査・対応）" --> UseCase1["【① コーディングエージェント流用型】<br>agy / Claude Code を直接起動して丸投げ<br>➔ 最速・最も柔軟・工数ゼロ"]
 
 Q1 -- "Yes（無人自走させたい）" --> Q2{"標準的な特定用途か？<br>（Slack執事、K8s診断など）"}
 
 Q2 -- "Yes（既存パッケージで足りる）" --> UseCase3["【③ 専用エージェント型】<br>OpenClaw や K8sGPT を導入<br>➔ 設定だけで即稼働"]
 
 Q2 -- "No（社内システム連携や厳格な安全基準）" --> UseCase2["【② プロコード自作型】<br>Antigravity Python SDK でパイプライン構築<br>➔ 堅牢・セキュア・完全自動"]

まとめ

「AI コーディングエージェント」という名称は、この技術の進化の出発点を表しているに過ぎません。

エディタの中（GUI / VS Code 拡張機能）: 人間の直感を研ぎ澄ます「ペアプログラマ」
ターミナルの中（CLI / agy）: タスクを丸投げして並行自走させる「自律エンジニア / 運用オペレータ」
プログラムの中（Python SDK）: 業務パイプラインを裏で駆動する「汎用自律オペレータ基盤」

Antigravity に Python SDK が用意されている理由は、エージェントの推論・実行ループをあらゆる業務自動化の「部品」として解放するため です。

開発用途という枠組みを外し、手元のトラブルシュートには CLI を、定常的な無人運用には Python SDK や専用エージェントを使い分けることで、次世代の自律運用体制を構築できます。

参考リンク・情報ソース

Antigravity エコシステムの全体像：VS Code 拡張機能・Antigravity 2.0・agy CLI・Python SDK の役割と使い分け

Sat, 22 Aug 2026 23:30:00 +0000

個人用メモ・備忘録

はじめに

2026 年 8 月 19 日、Google Antigravity の VS Code 向け公式拡張機能（Antigravity Extension for VS Code） がリリースされました。

これまでスタンドアロンの AI エディタ（Antigravity IDE）やデスクトップアプリ（Antigravity 2.0）、ターミナル用 CLI（agy）で提供されていた自律エージェント機能が、使い慣れた通常の VS Code 環境へ直接アドオンできるようになりました。

「従来の Gemini Code Assist と何が違うのか？」「デスクトップアプリ（Antigravity 2.0）や CLI（agy）とはどう使い分ければよいのか？」という疑問を持つ開発者も多いはずです。

本記事では、Gemini Code Assist から Antigravity への進化の背景、共通するエージェントコアのアーキテクチャ、そして 4 つの提供形態（Surfaces: VS Code 拡張機能、Antigravity 2.0、agy CLI、Python SDK）の特徴と実務での使い分け を整理します。

開発者 AI が直面していた「形態の分断」と進化の必然性

AI を活用したコーディング支援は、インラインのコード補完（Tab）やチャットウィンドウでの対話から始まりました。しかし、開発規模が大きくなるにつれて以下のような構造的課題が顕在化しました。

「提案」止まりによる手動作業のボトルネック:
- 従来の Gemini Code Assist や一般的な AI 拡張機能は、コード修正やコマンドをチャット欄で「提案」し、ユーザーが手動でエディタに貼り付け、ターミナルで実行してエラーが出たら再度チャットに貼る、という対話が中心でした。
手動モード切り替え（Ask / Edit / Agent）の煩雑さ:
- 「質問だから Ask」「特定行の修正だから Edit」「自動実行させたいから Agent」と、作業ごとに手動で UI モードを切り替える必要がありました。
作業環境によるツールの分断:
- GUI エディタ上では便利な補完が効く一方、SSH 先のリモートサーバー、コンテナ内部、あるいは CI/CD スクリプトなどのターミナル環境では同じ AI 支援を利用しにくいという断片化がありました。

【従来の開発スタイル（受動型）】
ユーザーが指示 ➔ AI がコード提案 ➔ ユーザーが手動適用 ➔ ユーザーが手動テスト ➔ エラーを目視確認

【Antigravity の自律ループスタイル（エージェント型）】
ユーザーがゴールを指示 ➔ AI が計画策定 ➔ ファイル自律編集 ➔ テスト・ビルドを自律実行 ➔ エラーを読み取り自己修復

Antigravity は、これらの課題を解消し、「単一のエージェントコアエンジンを、エディタ・デスクトップ・ターミナル・プログラムの 4 つの窓口（Surfaces）から一貫して利用できるプラットフォーム」として再設計されました。

共通基盤アーキテクチャ（Shared Agent Core）

Antigravity のすべてのツール（拡張機能、デスクトップ、CLI、SDK）は、独立した別々の製品ではなく、共通のエージェント基盤 を共有しています。

flowchart TD
 subgraph SharedCore ["共通コア基盤（Shared Agent Core）"]
 Gemini["Gemini 基盤モデル<br>（超長文コンテキスト / 高速推論）"]
 MCP["MCP (Model Context Protocol)<br>（GitHub, DB, クラウド等の外部ツール接続）"]
 Custom["カスタマイズ層<br>（Agent Skills, Rules: AGENTS.md, Hooks）"]
 Sandbox["安全サンドボックス & パーミッションエンジン"]
 Gemini --- MCP --- Custom --- Sandbox
 end

 SharedCore --> Surface1["1. VS Code 拡張機能<br>（エディタ直結・インライン補完・Diff）"]
 SharedCore --> Surface2["2. Antigravity 2.0<br>（デスクトップ司令塔・Cron 定期実行）"]
 SharedCore --> Surface3["3. agy (CLI)<br>（ターミナル特化・SSH / コンテナ / スクリプト）"]
 SharedCore --> Surface4["4. Python SDK<br>（プログラム組み込み・自律パイプライン）"]

共通コアが提供する 4 大要素

Gemini 基盤モデル:
- 巨大なコンテキストウィンドウと高速・低遅延な推論により、リポジトリ全体のコンテキストを把握しながら自律ループを駆動。
Model Context Protocol (MCP):
- Linux Foundation（AAIF）傘下で標準化されたオープン規格に準拠し、GitHub MCP やデータベース接続、カスタムツールを共通で利用可能。
オープンな設定・スキル規格:
- プロジェクト固有のルールは AGENTS.md、定型タスク手順は Agent Skills（SKILL.md）、統合パッケージは Agent Plugins（plugin.json）として全サーフェス共通で読み込み。
安全なサンドボックス & パーミッション:
- ターミナルコマンドの実行ポリシー（許可・確認・サンドボックス隔離）を共通ルールで制御。

提供形態（Surfaces）の比較と特徴

共通コアの上に構築された 4 つのインターフェースは、開発者の作業シーンに応じて最適化されています。

ツール / サーフェス	インターフェース	主な役割	代表的な利用シーン
VS Code 拡張機能	GUI エディタ統合	エディタ直結ペアプログラマ	日常のコーディング、インライン補完（Tab）、選択範囲のピンポイント修正（`Ctrl+I`）、Visual Diff 確認
Antigravity 2.0	デスクトップアプリ (Electron)	エージェント司令塔	プロジェクト横断管理、定期自動化タスク（Cron）、エディタから独立したチャットキャンバス
`agy` (CLI)	ターミナル (CUI / TUI)	ターミナル特化エージェント	SSH 先サーバー、コンテナ内作業、キーボード完結の高速操作、CI / スクリプト自動化（`-p`）
Python SDK	Python ライブラリ	プログラム組み込み	Python スクリプトからのエージェント呼び出し、自律評価パイプライン、カスタム CLI 開発

1. VS Code 拡張機能（エディタ一体型）

2026 年 8 月 19 日に正式提供が開始された拡張機能です。使い慣れた VS Code の設定、テーマ、拡張機能、Dev Containers 環境をそのまま維持しながら Antigravity を利用できます。

[ VS Code エディタ画面 ]
┌───────────────────────────────┬───────────────────────────────┐
│ 1. エディタ領域 │ 3. サイドバーチャット │
│ - Antigravity Tab (補完) │ - Agent Mode (自律実行) │
│ - Supercomplete (一括差分) │ - Planning Mode (計画承認) │
│ - Ctrl+I (インライン編集) │ - サブエージェント監視 │
│ - インライン Diff 表示 │ │
├───────────────────────────────┴───────────────────────────────┤
│ 2. 統合ターミナル / Problems 自動修正（1 クリック修復） │
└───────────────────────────────────────────────────────────────┘

主な機能

Antigravity Tab / Supercomplete:
- カーソル位置での単行補完だけでなく、複数行にわたる一括差分（削除・追加・import の自動挿入）を Tab キー 1 つで適用。
Inline Command (Ctrl+I / Cmd+I):
- 対象コードをハイライトしてショートカットを押し、「この関数に型アノテーションを追加して」とピンポイントで指示。
Visual Diff Overlays:
- エディタのコード上に直接赤緑のインライン Diff が表示され、変更内容を目視で確認しながら個別に採否を決定可能。
Problems 連携:
- コンパイラエラーや Linter の警告から「Fix with Agent」を 1 クリックして自動修正。

2. Antigravity 2.0（デスクトップ司令塔）

IDE（エディタ）の画面とは独立して動作する、スタンドアロンのデスクトップ Electron アプリケーションです。

主な機能

プロジェクト横断管理:
- 複数のリポジトリやワークスペースを左サイドバーで切り替え、並行してエージェントにタスクを委譲。
定期実行タスク（Scheduled Tasks / Cron）:
- 「毎朝 9 時に依存関係の脆弱性をスキャンする」「1 時間ごとにビルド状況をチェックする」といった Cron スケジュールを GUI 上で設定・監視。
独立したチャットキャンバス:
- エディタの表示領域を狭めることなく、大画面でエージェントとの設計議論や implementation_plan.md のレビューに専念。

3. Antigravity CLI (`agy`)（ターミナル特化）

GUI を持たない環境や、ターミナルからキーボード操作のみで爆速で作業したい開発者向けの公式 CUI / TUI ツールです。

主な機能

ターミナル完結の対話型 TUI:
- ターミナルで agy を起動するだけで、スラッシュコマンド（/help, /plan）や @ メンションを使った対話が可能。
ヘッドレス / リモート環境対応:
- GUI が存在しない SSH 先のクラウド VM や、Docker コンテナ内部でもそのまま動作。
非対話モード（-p / Prompt）による自動化:
- agy -p "Issue #42 の内容を修正してテストを実行" のように、シェルスクリプトや CI パイプラインからエージェントを直接呼び出してタスクを完遂。

# 対話型 TUI の起動
agy

# 非対話型でのワンショット実行（CI / スクリプト連携）
agy -p "全ファイルの型チェックを行い、エラーがあれば修正してください"

4. Antigravity Python SDK（プログラム組み込み）

Python コードから直接エージェントを呼び出し、カスタムな自律ワークフローや評価スクリプトを構築するための公式 SDK です（PyPI: google-antigravity）。

import asyncio
from google.antigravity import Agent, LocalAgentConfig, CapabilitiesConfig

async def main():
 # デフォルトは安全のため読み取り専用（Read-only）。
 # ファイル編集やコマンド実行を許可する場合は CapabilitiesConfig() を指定する。
 config = LocalAgentConfig(
 system_instructions="あなたはコード品質を検証する専門エージェントです。",
 capabilities=CapabilitiesConfig(),
 )

 async with Agent(config) as agent:
 # 非同期ストリーミングでエージェントと対話
 response = await agent.chat("tests/ 配下のユニットテストを実行して結果を要約して")
 async for token in response:
 print(token, end="", flush=True)
 print()

if __name__ == "__main__":
 asyncio.run(main())

主な特徴と用途

デフォルト安全設計（Read-only デフォルト）:
- CapabilitiesConfig() を明示しない限りツール実行（ファイル書き込みやシェル実行）がブロックされ、安全にコードベースを探索可能。
リアルタイム可観測性（Streaming Thoughts / ToolCalls）:
- トークンだけでなく、エージェントの思考ログ（response.thoughts）や呼び出されたツール（response.tool_calls）をプログラムからリアルタイムにフック・監視可能。
代表的なユースケース:
- テスト・デプロイ自動化パイプラインへの組み込み
- 社内専用のカスタム AI エージェント CLI 開発
- 大規模コードベースに対するバッチリファクタリングスクリプト

機能差の縮小によって浮き彫りになった「GUI と CLI の真の役割分担」

エージェント技術の進化初期、GUI（コード補完や対話チャット）と CLI（ファイル編集・自律ループ）の間には明確な「機能差」が存在し、住み分けは単純でした。

しかし現在、VS Code 拡張機能や Cursor などの GUI 側も「自律エージェント機能（ツール実行、ファイル編集、MCP 連携）」をフル装備し、カタログスペック上の機能差は大分縮まりました。

「GUI でもエージェントが動くなら、なぜ CLI を使うのか？」── 2025〜2026 年にかけて開発者コミュニティで白熱したこの疑問は、「Suggestion（提案・手元アシスト）」と「Delegation（委譲・自律自走）」という 2 つのパラダイムの違い によって鮮やかに解き明かされています。

Suggestion 型（提案）と Delegation 型（委譲）の設計思想の違い

Dev.to や国内外の開発者コミュニティの議論でも指摘されている通り、AI コーディング環境は以下の 2 つの設計思想に分化しています。

Suggestion-based（In-the-loop / 提案型）: 人間がエディタでコードを書く作業を 1 行ずつ手元で補完・アシストする（GUI エディタが最適）。
Delegation-based（Out-of-the-loop / 委譲型）: ゴールを指示してテスト・自己修復まで丸ごと任せて自走させる（ターミナル / CLI が最適）。
開発環境を「視覚的にコードを検分する工房（Studio）」と捉えるか、「コマンドで自律群を指揮する司令塔（Cockpit）」と捉えるかによって、最適解が異なります。

なぜバイブコーディングや自律実行では CLI が最適解なのか？

2025 年 2 月、AI 研究者の Andrej Karpathy 氏（元 OpenAI 共同創設者 / 元 Tesla AI ディレクター）は、AI 時代の新しい開発パラダイムとして 「バイブコーディング（Vibe Coding）」 を提唱しました。

Andrej Karpathy 氏による「バイブコーディング」の提唱

「構文（シンタックス）の細部を書く作業から完全に離れ、大まかな意図（バイブス）だけを自然言語で伝え、コードの存在すら忘れて指数関数的な開発速度に身を委ねる新しいコーディング様式」
── Andrej Karpathy 氏の X ポスト（2025 年 2 月 2 日）

このような「人間がコードを手書きするのではなく、AI に実装を一気に委譲して自律自走させる開発スタイル」において、なぜ GUI エディタではなく CLI（ターミナル環境）が決定打（最適解） となるのか？開発者コミュニティや AI 研究所の検証から、以下の 4 つのアーキテクチャ的要因が明らかになっています。

1. 直接実行力と低レイテンシ（High Agency & Native Habitat）

GUI の制約（提案・描画のオーバーヘッド）: GUI エディタ上の AI は、エディタの仮想 DOM 描画や UI 状態管理を挟むため、差分提示やダイアログ確認など「人間への提案（Suggestion）」が中心になりやすく、動作速度や自律性に制約がかかります。
CLI の優位性（OS レイヤーへの直結）: Anthropic の Claude Code や Aider の設計思想が示すように、ターミナルはエージェントにとっての「母艦（Native Habitat）」です。OS のシェル、ファイルシステム、Git、パッケージマネージャーに直接アクセスし、UI のオーバーヘッドなしに自律コマンドを高速実行できます。

2. 「コマンド検索」によるコンテキスト純度（S/N 比）の極大化

GUI の課題（暗黙コンテキストによる注意の希釈 / Context Pollution）: GUI エディタの AI は利便性のために「開いているタブ」や周辺ファイルを自動的にプロンプトへ詰め込みます。しかし、大規模なコードベースにおいて無関係なファイルが混入すると、Attention Dilution（注意の希釈 / Lost in the Middle 現象） が発生し、指示の見落としやハルシネーションの原因になります。
CLI の優位性（外科手術のような高純度コンテキスト）: CLI 環境のエージェントは、rg（ripgrep）、fd、jq、git log などの高速な UNIX ツールを自ら実行し、「該当する関数の前後 10 行だけ」「直近のエラーログのスタックトレースだけ」を外科手術のようにピンポイントで切り出してプロンプトに注入（Progressive Disclosure）します。不要なノイズを完全に削ぎ落とし、コンテキストの S/N 比を極大化することで、推論とコード修正の精度が劇的に向上します。

3. 「作って終わり」にしない自己検証・修復ループ（Execution-Feedback Loop）

バイブコーディングの本質は、コードを一括生成した後の 「テストが通るまでの自走・自己修復（Test-Driven Self-Correction）」 にあります。

実行環境直結の強み: Princeton 大学の SWE-agent / SWE-bench 等の研究でも実証されている通り、自律エージェントの成功率は「コードを生成した直後にシェル環境で即座にビルド・テストを実行し、その標準出力・エラーメッセージをフィードバックとして受け取れるか」に大きく依存します。
CLI の完走力: CLI 環境のエージェントは、コード修正直後に自ら npm test や pytest、go test を叩き、型エラーやテスト落ちを検知して自律修正するループを何ターンでも完走させます。人間が画面に戻ってきた時には、すでにテストをパスした検証済みの完成品が出来上がっています。

4. マルチプレキシング（5〜10 台以上の並列同時自走）

Anthropic の Claude Code 開発リードである Boris Cherny 氏らが実践し提唱している最大の生産性ハックが 「マルチプレキシング（Agent Multiplexing / 並列自走）」 です。

git worktree による作業の完全隔離: git worktree を使って作業ツリーとブランチを分離し、ターミナル上で 5〜10 台以上のエージェント（agy や Claude Code）を同時に並行自走 させます（Issue 調査、API 実装、テスト追加、ドキュメント更新を同時進行）。
オーケストレーターへの進化: GUI エディタで 5 つ以上のウィンドウを開いてエージェントを動かすと、タブが氾濫して画面が崩壊し、メモリ消費で開発マシンが悲鳴を上げます。「エージェントの群れ（Swarm）を指揮するオーケストレーター」として動く場合、軽量で画面を奪わず、バックグラウンド実行や通知と親和性の高いターミナル / CLI こそが唯一の現実解となります。

提供形態ごとの最終的な役割分担

開発のフェーズ・目的	要求されるコア技術	最適なツール
① 大規模自律実行 & バイブコーディング（機能一括構築、重いリファクタ、無人CI）	・高密度なコンテキスト収集（`rg`/`jq`）・制限のないシェル実行（Tool Space）・`git worktree` による並列分散自走	CLI 版 (`agy`)
② 人間主導の手元アシスト（Tab補完、1行修正、型エラー即時修正）	・エディタ未保存メモリ/LSP への同期・カーソル座標のリアルタイム把握・インライン赤緑 Diff レビュー	VS Code 拡張機能

flowchart LR
 Dev["開発者"]
 
 Dev -->|"① 人間が主導権を握る作業（タイピング・即時修正）"| VSCode["VS Code 拡張機能<br>（Tab 補完 / Ctrl+I / インライン Diff）"]
 Dev -->|"② AI に主導権を渡す作業（タスク丸投げ・並列自走）"| CLI["agy (CLI)<br>（tmux 並列自走 / CI 自動化）"]
 Dev -->|"③ 定常監視・プロジェクト横断"| App["Antigravity 2.0<br>（Cron スケジュール / 司令塔）"]
 Dev -->|"④ スクリプト・評価パイプライン"| SDK["Python SDK<br>（プログラム組み込み）"]

まとめ

機能差が縮まった現在、それぞれのツールの存在価値は以下のように美しく整理されます。

エージェントの「頭脳・自律能力・調査力・完走力」を最大化したいとき（バイブコーディング、重いタスク、自動化） ➔ CLI 版（agy）が機能的・アーキテクチャ的に絶対の最適解。
「人間がエディタでコードを書く作業を、手元で気持ちよくアシストさせたいとき（補完・即時修正）」 ➔ GUI 版（VS Code 拡張機能）が UI として最適。

状況に応じて最適なインターフェースを選択・併用することで、AI エージェントの自律性を最大限に引き出した開発環境を構築できます。

参考リンク・情報ソース

Python 開発を効率化するモダンターミナル環境設計：Ghostty・fish・peco・ghq・tmux・Jujutsu・VS Code・Herdr・Hunk 連携

Sat, 22 Aug 2026 08:50:00 +0000

個人用メモ・備忘録

はじめに

複数の Python プロジェクト（FastAPI アプリ、CLI ツール、データ処理バッチ、ライブラリ等）を並行して開発する際、以下のような操作摩擦が積み重なり、作業の中断やコンテキストスイッチのコストを生み出します。

ディレクトリ移動の手間: 階層の深いプロジェクトパスを cd コマンドで手動入力する。
バックグラウンドプロセスの消失: ローカルサーバーやテスト監視、ワーカープロセスを起動したターミナルを閉じるとプロセスが終了してしまう。
仮想環境（venv / uv）の切り替え忘れ: プロジェクトを移動するたびに手動で activate する必要がある。
Git のコミット・ブランチ操作の煩雑さ: AI や人間による頻繁な試行錯誤（スクラップ＆ビルド）で、コミットログが汚れたりコンフリクト解消に工数がかかる。
GUI エディタや差分レビューへの切り替えコスト: ターミナルからエディタ（VS Code）や Git 差分確認画面への行き来に手間がかかる。

これらの課題を解消し、「端末起動 ➔ リポジトリ選択 ➔ 仮想環境アクティベート ➔ セッション復元 ➔ 安全なバージョン管理・差分レビュー」までを一気通貫で高速化するターミナル駆動開発環境（Terminal-Driven Development Stack）を構築します。

本記事では、Ghostty、fish、peco、ghq、tmux / herdr、Jujutsu (jj)、hunk、および VS Code を組み合わせた実践的な設計と設定方法を整理します。

ツールスタックとそれぞれの役割（レイヤー構造）

開発環境を構成するツール群を、インフラ（端末）からアプリケーション（エディタ・VCS）までの階層で整理します。

+------------------------------------------------------------------------+
| [Application Layer] |
| - VS Code : GUI エディタ / デバッグ / Dev Containers |
| - Jujutsu (jj) : 次世代 Git 互換 VCS（自動コミット / 完全 Undo） |
| - hunk : Review-First TUI 差分レビュー / 部分ステージング |
+------------------------------------------------------------------------+
| [Session & Agent Layer] |
| - tmux / herdr : セッション永続化 / Agent-Aware 状態管理 |
+------------------------------------------------------------------------+
| [Shell & Navigation Layer] |
| - fish : オートサジェスト / 構文ハイライト / 関数フック |
| - ghq + peco : リポジトリ一元配置 ＋ あいまい検索ジャンプ |
| - uv : 高速 Python パッケージ管理 / 仮想環境自動連携 |
+------------------------------------------------------------------------+
| [Terminal Emulator Layer] |
| - Ghostty : Zig 製・GPU 高速描画 / 低遅延 / ネイティブ UI |
+------------------------------------------------------------------------+

各ツールの役割と導入メリット

ツール	レイヤー	単体での役割	導入後のメリット
`Ghostty`	ターミナル	GPU 描画ターミナルエミュレータ	低遅延・高速レンダリング、ネイティブなタブ/画面分割、Kitty グラフィックス対応
`fish`	シェル	設定不要で賢いシェル	過去履歴の予測補完（オートサジェスト）や構文エラー検知がプラグインなしで動作
`ghq`	ナビゲーション	リポジトリ配置の自動統一	`ghq get <URL>` で `~/ghq/github.com/...` に自動整理。置き場所の迷いを排除
`peco`	ナビゲーション	対話型インクリメンタルフィルタ	キーワード入力だけで大量の候補から瞬時に選択・決定
`tmux`	セッション	ターミナルマルチプレクサ	ターミナルを閉じても裏でサーバーやテストが維持され、作業空間を丸ごと復元
`herdr`	セッション	Agent-Aware マルチプレクサ	各ペインで稼働する AI エージェントの状態（working / blocked / done）を自動検知
`Jujutsu (jj)`	VCS	次世代 Git 互換バージョン管理	作業コピーの自動コミット、全操作の `jj undo`、コンフリクトを恐れないスタック開発
`hunk`	レビュー	Review-First TUI 差分ビューア	AI や自身が変更したコード差分をインラインで高速レビューし、行単位で安全にステージング
`VS Code`	エディタ	GUI エディタ / デバッグ	`code <path>` で CLI から瞬時に開き、GUI デバッガや Dev Containers と連携

Ghostty：高速・低遅延な GPU ターミナル基盤

Ghostty (ghostty.org) は、Mitchell Hashimoto 氏が開発した Zig 製の GPU アクセラレーテッドターミナルエミュレータです。

GPU レンダリングによる高速描画: GPU アクセラレーションにより、大容量のログ出力や高速スクロールでもカクつかず低遅延で動作。
ネイティブ UI 統合: macOS や Linux のネイティブ UI を採用し、タブやスプリットペインを軽快に操作可能。
モダンプロトコル対応: Kitty グラフィックスプロトコルや TrueColor、アンダーライン装飾に対応し、TUI ツール（hunk, peco 等）が美しく描画されます。

ghq によるリポジトリ管理の統一

ghq は、Git リポジトリのクローン先を決められたディレクトリ構造（デフォルトは ~/ghq/github.com/owner/repo）に自動で整理・配置するツールです。

# リポジトリのクローン
ghq get https://github.com/fastapi/fastapi.git
ghq get owner/my-python-project

# パス一覧の確認
ghq list -p
# /home/user/ghq/github.com/fastapi/fastapi
# /home/user/ghq/github.com/owner/my-python-project

fish ＋ peco による 1 キープロジェクト移動

fish のキーバインドに ghq list -p | peco を組み込むことで、Ctrl + ] を押すだけで全リポジトリを検索してジャンプする環境を構築します。

関数の実装 (`~/.config/fish/functions/fish_user_key_bindings.fish`)

function peco_select_ghq_repository
 set -l repo_path (ghq list -p | peco --query (commandline))
 if test -n "$repo_path"
 cd $repo_path
 commandline -f repaint
 end
end

function fish_user_key_bindings
 bind \c\] peco_select_ghq_repository
end

tmux / herdr によるセッション永続化と AI 状態管理

tmux：プロジェクト単位の作業部屋自動作成

ディレクトリ移動と同時に、プロジェクト専用の tmux セッションを作成またはアタッチします。

function peco_open_ghq_tmux
 set -l repo_path (ghq list -p | peco --query (commandline))
 if test -z "$repo_path"
 return
 end

 set -l session_name (basename $repo_path | tr '.' '_')

 if test -z "$TMUX"
 if tmux has-session -t $session_name 2>/dev/null
 tmux attach-session -t $session_name
 else
 tmux new-session -s $session_name -c $repo_path
 end
 else
 if not tmux has-session -t $session_name 2>/dev/null
 tmux new-session -d -s $session_name -c $repo_path
 end
 tmux switch-client -t $session_name
 end
 commandline -f repaint
end

herdr：AI エージェント協働時代のマルチプレクサ

AI コーディングエージェント（Claude Code、Codex、Antigravity 等）をバックグラウンドで並行稼働させる場合、herdr (github.com/ogulcancelik/herdr) が力を発揮します。

エージェント状態の自動認識: 各ペインの AI が作業中（working）、入力待ち（blocked）、完了（done）かを自動検知。
tmux 互換のセッション永続化: バックグラウンドでのプロセス維持とエージェント監視ダッシュボードを両立。

Python 仮想環境（uv / venv）の自動アクティベーション

ディレクトリ移動時に、カレント配下の .venv を自動で有効化します。

~/.config/fish/functions/auto_activate_venv.fish:

function auto_activate_venv --on-variable PWD --description "ディレクトリ移動時に .venv を自動アクティベート"
 if test -n "$VIRTUAL_ENV"
 set -l venv_parent (dirname $VIRTUAL_ENV)
 if not string match -q "$venv_parent*" "$PWD"
 deactivate
 end
 end

 if test -f "$PWD/.venv/bin/activate.fish"
 if test "$VIRTUAL_ENV" != "$PWD/.venv"
 source "$PWD/.venv/bin/activate.fish"
 end
 end
end

Rust 製の高速パッケージマネージャー uv（uv venv ➔ uv pip install ...）と組み合わせることで、ミリ秒単位で環境構築が完了します。

Jujutsu（jj）：Git 互換の次世代バージョン管理

Jujutsu (jj) (github.com/martinvonz/jj) は、Google 発の Rust 製次世代分散バージョン管理システムです。既存の Git リポジトリ（.git）上でそのまま透過的に動作します。

+-------------------------------------------------------------+
| Jujutsu (jj) CLI |
| - 作業コピーの自動追跡（Working-copy Commit） |
| - 全操作の履歴管理と完全な巻き戻し（jj undo / op log） |
| - コンフリクトの第一級オブジェクト化（作業をブロックしない）|
+-------------------------------------------------------------+
 │ (バックエンドとして共存)
 ▼
+-------------------------------------------------------------+
| Standard Git Repository (.git) |
| - GitHub リモートリポジトリとの通信・Push/Pull |
+-------------------------------------------------------------+

なぜ Python 開発 / AI 協働で `jj` が強力なのか？

git commit を手動で打つ必要がない（Working-copy Commit）:
- ファイルを保存した瞬間、自動で背後にコミット（Change ID）が作成されます。「コミットし忘れて作業ツリーを汚す」心配がありません。
どんな破壊的変更も一発で巻き戻せる (jj undo):
- jj はすべての操作をオペレーションログ（jj op log）に記録しているため、AI がコードを壊したりリベースを誤っても、jj undo コマンド 1 つで完全に直前の状態へ戻せます。
ブランチを切らずに複数の作業をスタックできる（Stacked Changes）:
- 変更（Change）を積み重ねて管理でき、作業ごとのブランチ作成・切り替えの手間を大幅に削減します。

# 既存の Git リポジトリで jj を初期化
jj git init --colocate

# 現在の状態確認（コミットツリーと変更内容が即座に表示される）
jj status
jj log

# 失敗した変更を直ちに巻き戻す
jj undo

差分レビューと部分コミットの高速化「hunk」

hunk (modem-dev/hunk) は、ターミナル上でリッチなコードレビュー体験を提供する Review-First TUI ツールです。

ファイルツリー付きの差分レビュー: 変更された全ファイルをツリー形式で確認し、キーボードで素早く移動。
インラインレビュー: AI が生成したコードの修正理由やアノテーションを差分上で直接確認。
部分ステージング: git add -p のように対話的に質問されず、TUI 上で必要な行を選択して直感的にコミット対象に含めることが可能。

VS Code 連携：CLI からのワンショット起動

ターミナルの高速ナビゲーションと、VS Code のデバッガ・GUI 機能を繋ぎます。

function peco_open_ghq_vscode
 set -l repo_path (ghq list -p | peco --query (commandline))
 if test -n "$repo_path"
 code $repo_path
 end
 commandline -f repaint
end

推奨設定ファイル一覧

`~/.config/fish/config.fish`

# PATH の設定
fish_add_path ~/.local/bin
fish_add_path /opt/homebrew/bin

# 仮想環境のプロンプト装飾を無効化
set -gx VIRTUAL_ENV_DISABLE_PROMPT 1

# コマンド履歴検索（Ctrl + R）で peco を使用
function peco_select_history
 history | peco | read -l selected
 if test -n "$selected"
 commandline $selected
 end
end

function fish_user_key_bindings
 bind \c\] peco_select_ghq_repository # プロジェクト移動 (cd)
 bind \co peco_open_ghq_tmux # tmux セッション起動/アタッチ
 bind \cv peco_open_ghq_vscode # VS Code で開く
 bind \cr peco_select_history # 履歴検索
end

`~/.tmux.conf`（抜粋）

# プレフィックスキーを Ctrl + q に変更
set -g prefix C-q
unbind C-b
bind C-q send-prefix

# TrueColor の有効化
set -g default-terminal "screen-256color"
set -ga terminal-overrides ",xterm-256color:Tc"

# マウス操作の有効化
set -g mouse on

# Vim ライクなペイン移動
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R

# 新規ウィンドウ・ペインをカレントディレクトリで開く
bind c new-window -c "#{pane_current_path}"
bind % split-window -h -c "#{pane_current_path}"
bind '"' split-window -v -c "#{pane_current_path}"

まとめ

基盤（Ghostty ＋ fish）: GPU レンダリングの高速端末と設定不要の賢いシェルで操作の遅延を排除。
ナビゲーション（ghq ＋ peco ＋ uv）: リポジトリ配置を標準化し、1 キー移動＋仮想環境の自動アクティベートを実現。
セッション（tmux / herdr）: 作業状態を永続化し、AI エージェントの並行タスクをダッシュボード管理。
バージョン管理・レビュー（Jujutsu ＋ hunk ＋ VS Code）: 自動コミットと完全 Undo（jj）で試行錯誤を安全化し、TUI（hunk）と GUI（VS Code）で差分確認とデバッグを最適化。

参考リンク・情報ソース

Model Context Protocol（MCP）の仕様と設計：AI と外部ツールを繋ぐオープン標準

Sat, 22 Aug 2026 08:40:00 +0000

個人用メモ・備忘録

はじめに

AI コーディングエージェントにデータベースのスキーマを取得させたり、GitHub の Issue や PR を操作させたり、社内 API と連携させる際、以前はエージェント製品ごとに個別の連携コードや独自拡張を書く必要がありました。

この「エージェントと外部ツールの個別結合（1 対 N の断片化）」を解消するために策定されたオープン標準規格が Model Context Protocol（MCP） です。

かつて開発環境において IDE とプログラミング言語の解析エンジンを分離した Language Server Protocol（LSP） と同様に、MCP は 「LLM（クライアント）」と「外部データ・ツール（サーバー）」を疎結合な共通プロトコルで接続 します。

本記事では、MCP の誕生背景とオープン標準化（Linux Foundation 移管）の経緯、3 大基本機能（Tools / Resources / Prompts）、通信トランスポート（Stdio / SSE）、安全な設定方法、および TypeScript / Python による自作サーバーの実装設計をまとめます。

MCP の誕生とオープン標準化（AAIF 移管）

MCP は、2024 年 11 月に Anthropic によって提唱・オープンソース化されました。

当初から特定ベンダーに縛られないオープン規格として設計されていましたが、2025 年 12 月 9 日、中立なガバナンスのもとで業界標準として普及させるため、Linux Foundation 傘下の Agentic AI Foundation (AAIF) へ正式に寄贈・移管されました。

【LSP のアプローチ】
エディタ（VS Code, Neovim 等） <── [ LSP ] ──> 言語サーバー（TypeScript, Go, Rust 等）

【MCP のアプローチ】
エージェント（Antigravity, Claude, Cursor 等） <── [ MCP ] ──> ツール・データサーバー（GitHub, DB, Slack 等）

現在では Anthropic 製品に限らず、Google Antigravity、Cursor、Microsoft、OpenAI Codex などの主要なエージェント基盤や、統合パッケージ規格 Agent Plugins 1.0.0 におけるツール接続のコア仕様として採用されています。

アーキテクチャと通信モデル

MCP は、Host（親アプリケーション）、Client（プロトコル仲介）、Server（ツール提供元） の 3 層アーキテクチャで構成されます。

通信には JSON-RPC 2.0 を採用しており、標準化されたリクエスト / レスポンスおよび通知メッセージによってやり取りされます。

flowchart TD
 subgraph Host ["Host（Antigravity, Cursor, Claude Code 等）"]
 Agent["LLM / エージェント推論ループ"]
 Client["MCP Client（プロトコル中継・接続管理）"]
 Agent <-->|"ツール呼び出し要求 / 結果返却"| Client
 end

 subgraph Server1 ["MCP Server A（ローカル実行）"]
 T1["Tools（SQL 実行・ファイル操作）"]
 R1["Resources（スキーマ・ログ）"]
 end

 subgraph Server2 ["MCP Server B（リモート / クラウド）"]
 T2["Tools（GitHub PR 作成・Issue 取得）"]
 P2["Prompts（レビューテンプレート）"]
 end

 Client <-->|"Stdio（stdin / stdout パイプ）"| Server1
 Client <-->|"SSE / HTTP（ネットワーク通信）"| Server2

3 つのコンポーネント

Host:
- エージェントの実行環境（Antigravity CLI、Cursor、Claude Desktop 等）。ユーザーの指示を受け取り、LLM による推論ループを駆動します。
Client:
- Host 内部で動作し、各 MCP サーバーとの 1 対 1 のセッションを管理するモジュール。サーバーの機能一覧（Capabilities）を取得し、LLM からの呼び出し要求を JSON-RPC メッセージに変換して中継します。
Server:
- 外部ツールやデータソースを公開する独立した軽量プロセス（またはリモートサービス）。Host から要求されたツール実行やデータ読み込みを行い、結果を返却します。

通信トランスポート（Stdio と SSE）

MCP クライアントとサーバー間の通信レイヤー（Transport）には、主に 2 つの方式が定義されています。

トランスポート方式	通信経路	主なユースケース	特徴
Stdio Transport	標準入出力（stdin / stdout）	ローカル開発環境、CLI、ローカル DB 操作	ホストからサブプロセスとして直接起動。ネットワーク不要で高速かつセキュア
SSE Transport	Server-Sent Events ＋ HTTP POST	クラウドサービス、社内共有 API サーバー	リモートサーバーとの通信に対応。インフラとして常駐稼働させる場合に利用

ローカル開発環境（DevContainer やローカル端末）では、設定ファイルにコマンドを記述するだけでオンデマンドに起動・破棄できる Stdio Transport が最も一般的に利用されます。

中核機能（Primitives）の構成

MCP サーバーは、エージェントに対して以下の 3 種類のプリミティブを公開できます。

MCP Server
├── 1. Tools # エージェントが実行する関数（副作用あり・JSON Schema 検証）
├── 2. Resources # エージェントが参照するデータ（読み取り専用・URI 形式）
└── 3. Prompts # 定型プロンプトのテンプレート（スラッシュコマンド・ワークフロー）

1. Tools（ツール実行）

エージェントが自律的に呼び出す関数（Function Calling）を定義します。

特徴: 引数のバリデーションに JSON Schema を使用し、決められた形式でのみ安全に呼び出されます。
副作用: ファイルの書き込み、PR の作成、SQL の実行など、状態変更を伴う操作が含まれます。
例: create_pull_request, query_database, execute_search

2. Resources（コンテキストデータ供給）

エージェントがオンデマンドで読み込むための、URI 形式で識別されるデータソースです。

特徴: 読み取り専用（Read-only）。テキストまたはバイナリデータを返します。
例: file:///var/log/app.log, postgres://schema/users, docs://api/v1

3. Prompts（対話テンプレート）

サーバー側で事前定義されたプロンプトやコンテキスト注入用テンプレートです。

特徴: エージェントのユーザーインターフェース上でスラッシュコマンド等として提示され、定型的な指示（コードレビュー指示、障害調査テンプレート等）を標準化します。

Rules・Skills・Agent Plugins との役割分担

AI エージェントの拡張アーキテクチャ全体における MCP の位置づけです。

規格 / 要素	管理ファイル	役割・定義	読み込みタイミング
Rules	`AGENTS.md`	プロジェクト全体の共通規約・制約・Guardrails	毎ターン常時ロード
Skills	`SKILL.md`（agentskills.io）	特定タスクの専門手順書・実行スクリプト	タスク発生時にオンデマンド展開
MCP	`mcp_config.json`（modelcontextprotocol.io）	外部データ・API 連携の型安全な接続インターフェース	プラグイン起動時に常駐接続
Plugins	`plugin.json`（agentplugins.io）	上記の Rules / Skills / MCP を 1 つに束ねた統合パッケージ	インストール・有効化時に一括管理

Agent Skills と比較した MCP の 5 つの固有メリット

「特定タスクの手順を実行する」という目的において、Agent Skills（SKILL.md ＋ scripts/） と MCP は一見似ているように見えますが、設計思想と技術的アプローチが根本的に異なります。

比較項目	Agent Skills (`SKILL.md` ＋スクリプト)	Model Context Protocol (MCP)
実行モデル	エージェントによる任意のシェルコマンド実行	Host 仲介による型定義された RPC 関数呼び出し
引数・型検証	プロンプト（自然言語）頼み。構文エラーやインジェクションのリスクあり	JSON Schema による事前バリデーション。不正な型・引数を物理遮断
セキュリティ境界	ターミナル実行権限が必要（ホスト破壊のリスク）	ホワイトリストされた API のみ許可（ターミナル権限不要）
通信・配置	ローカルファイルシステム上のスクリプトに依存	Stdio（ローカル）＋ SSE / HTTP（リモート）に対応
接続・状態管理	コマンド実行ごとにプロセスが起動・終了（ステートレス）	サーバーが常駐し、DB コネクションプールや認証状態を維持
データ連携	静的なドキュメント読み込み	Resources による動的データ供給・リアルタイム購読

1. JSON Schema による厳格な型安全性と引数のバリデーション

Skills の課題: Skills のスクリプト（Bash/Python）を呼ぶ際、LLM は自然言語の指示からコマンドライン引数を組み立てます。文字列のクォート忘れ、エスケープ漏れ、型の解釈ブレによる実行時エラーや、意図しないコマンドインジェクションが発生するリスクがあります。
MCP の優位性: MCP はすべての Tool に JSON Schema の定義を強制します。Host（クライアント）が LLM の生成した JSON 引数をスキーマと照合し、型や必須項目が不正な場合は実行前に自動でエラーを検知・再生成を促す ため、極めて決定論的で堅牢なツール呼び出しが保証されます。

2. ターミナル権限を開放しない「最小権限のセキュリティ」

Skills の課題: スクリプトを実行させるには、エージェントに「Bash / ターミナルツールの実行権限」を渡す必要があります。これは、エージェントが誤って他の重要ファイルを操作・削除してしまうリスクを常に内包します。
MCP の優位性: エージェントに ターミナル実行権限を一切与えることなく、MCP サーバーが公開した「特定の関数（例: get_issue, query_readonly_db）」のみを選択的に実行させることができます。これにより、最小権限の原則（Principle of Least Privilege）を厳格に適用できます。

3. リモート・クラウド接続性と環境非依存のポータビリティ

Skills の課題: Skills はローカル環境にスクリプトファイルが存在し、そのスクリプトを実行できるランタイム（Python, Node.js, 各種 CLI ツール等）がホスト OS にインストールされている必要があります。
MCP の優位性: MCP は SSE（Server-Sent Events）や HTTP によるネットワーク越しの通信 を標準サポートしています。ホスト環境にランタイムを追加することなく、クラウド上の SaaS、社内共有のマイクロサービス、コンテナ外の API サーバーと直接接続して操作を委託できます。

4. 常駐プロセスによる「コネクションプール・セッションの維持」

Skills の課題: スクリプト呼び出しはコマンド実行ごとに新規プロセスが起動して終了するため、データベース接続の確立や OAuth ハンドシェイクを毎回ゼロからやり直す必要があります（オーバーヘッド大）。
MCP の優位性: MCP サーバーはセッション中ずっと常駐する独立プロセスとして稼働するため、DB コネクションプール、メモリキャッシュ、認証セッションを保持 したまま連続したクエリを低レイテンシで高速処理できます。

5. 動的なデータ購読（Resources と Live Notifications）

Skills の課題: エージェントが references/ 配下の静的 Markdown をオンデマンドで読むだけの「一方向・受動的」な情報取得に留まります。
MCP の優位性: Resources プリミティブを通じて、URI ベースで動的にデータを供給できるだけでなく、サーバー側でログやデータが更新された際に 更新通知（notifications/resources/updated）をクライアントへリアルタイムにプッシュ できます。

各クライアントでの設定とシークレット管理

設定ファイルの構造（`mcp_config.json` / `mcp.json`）

MCP サーバーの設定は、JSON 形式で起動コマンドと引数、環境変数を指定します。

{
 "mcpServers": {
 "github": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-github"],
 "env": {
 "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GITHUB_TOKEN}"
 }
 },
 "sqlite-db": {
 "command": "uvx",
 "args": ["mcp-server-sqlite", "--db-path", "./data/app.db"]
 }
 }
}

npx -y / uvx によるゼロインストール実行: Node.js 製サーバーは npx -y <pkg>、Python 製サーバーは uvx <pkg> を指定することで、事前にグローバルインストールすることなくオンデマンドで最新の隔離環境から実行できます。

WARNING

環境変数注入によるシークレット漏洩の防止 設定ファイルを Git でチーム共有したり外部配布する際、API キーやアクセストークンを生の文字列で記述してはなりません。${env:VAR_NAME} 形式を用いて、実行環境の環境変数から動的に注入します。

自作 MCP サーバーの実装例

1. TypeScript による実装（公式 SDK）

公式の @modelcontextprotocol/sdk を使用した、最小限のツール提供サーバーの実装例です。

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
 CallToolRequestSchema,
 ListToolsRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";

// 1. サーバーインスタンスの生成
const server = new Server(
 {
 name: "metrics-server",
 version: "1.0.0",
 },
 {
 capabilities: {
 tools: {},
 },
 }
);

// 2. 公開するツールの定義（一覧の返却）
server.setRequestHandler(ListToolsRequestSchema, async () => {
 return {
 tools: [
 {
 name: "get_service_metrics",
 description: "指定したサービスのエラー率とレイテンシ（P95）を取得する",
 inputSchema: {
 type: "object",
 properties: {
 serviceName: {
 type: "string",
 description: "対象サービス名（例: auth, payment, api-gateway）",
 },
 },
 required: ["serviceName"],
 },
 },
 ],
 };
});

// 3. ツール実行ハンドラの実装
server.setRequestHandler(CallToolRequestSchema, async (request) => {
 if (request.params.name === "get_service_metrics") {
 const serviceName = String(request.params.arguments?.serviceName);

 // 実際のメトリクス取得処理（例）
 const metricsData = {
 service: serviceName,
 errorRate: "0.02%",
 p95LatencyMs: 124,
 status: "healthy",
 };

 return {
 content: [
 {
 type: "text",
 text: JSON.stringify(metricsData, null, 2),
 },
 ],
 };
 }

 throw new Error(`未定義のツールです: ${request.params.name}`);
});

// 4. Stdio トランスポートで接続待機
const transport = new StdioServerTransport();
await server.connect(transport);

2. Python による実装（FastMCP）

Python 環境では、公式 SDK 内の FastMCP を使用することで、デコレータを用いて極めて簡潔に記述できます。

from mcp.server.fastmcp import FastMCP

# サーバーの初期化
mcp = FastMCP("SystemMetricsServer")

# ツールの定義（型ヒントと docstring が自動的に JSON Schema に変換される）
@mcp.tool()
def get_disk_usage(path: str = "/") -> str:
 """指定されたパスのディスク使用量と空き容量を取得する。
 
 Args:
 path: チェック対象のディレクトリパス
 """
 import shutil
 total, used, free = shutil.disk_usage(path)
 return (
 f"Path: {path}\n"
 f"Total: {total // (2**30)} GB\n"
 f"Used: {used // (2**30)} GB\n"
 f"Free: {free // (2**30)} GB"
 )

if __name__ == "__main__":
 mcp.run()

IMPORTANT

description と型アノテーションの重要性 LLM はツールの description と引数のスキーマ定義を読んで「どのツールを呼ぶべきか」「どんな引数を渡すべきか」を判断します。関数の目的、引数の具体例、戻り値のフォーマットを明確に記述することが、ツールの誤発動や引数エラーを防ぐ鍵となります。

セキュリティ設計と運用のベストプラクティス

最小権限の原則（Principle of Least Privilege）:
- データベース連携サーバーでは、更新・削除権限（INSERT/UPDATE/DELETE/DROP）を持たない Read-Only 専用ユーザー の認証情報を設定する。
物理サンドボックス（ハーネス）との多重防御:
- MCP 自体は「安全な API 呼び出し形式」を提供するプロトコルですが、サーバープロセスが動作する環境自体の安全性は Docker コンテナなどの物理サンドボックス（ハーネス）で隔離して担保する。
エラーメッセージの具体化:
- ツール実行が失敗した際は、単に例外を握りつぶすのではなく、「なぜ失敗したか（認証切れ、引数不正、対象レコード不在）」をテキストとして明瞭に返却し、エージェントが自己修復ループ内で次の手を判断できるように設計する。

まとめ

オープン標準化: Model Context Protocol（MCP）は Anthropic が提唱後、Linux Foundation 傘下の Agentic AI Foundation（AAIF）に移管された、ベンダーニュートラルなツール接続プロトコル。
3 大プリミティブ: 副作用を伴う Tools、コンテキスト供給の Resources、対話テンプレートの Prompts を JSON-RPC 2.0 で抽象化。
エコシステム統合: 常時ルールの AGENTS.md、手順書の Agent Skills、統合パッケージの Agent Plugins と組み合わせることで、ポータブルで安全なエージェント運用基盤を確立できる。

参考リンク・情報ソース

Agent Skills（agentskills.io）の仕様と設計：手順書の段階的開示とディレクトリ標準

Wed, 19 Aug 2026 23:30:00 +0000

個人用メモ・備忘録

はじめに

AI コーディングエージェントにデプロイ手順、データベースマイグレーション、障害調査などの定型タスクを実行させる際、すべての詳細手順を AGENTS.md などのルールファイルに記述すると、プロンプトが肥大化して Context Bloat（トークン消費の増大） が発生します。

さらに、スタンフォード大学などの研究 『Lost in the Middle』(Liu et al., 2023) が実証した通り、プロンプトが長大化するほど中盤に書かれた指示への注意（Attention）が著しく低下する Attention Dilution（重要指示の埋没・見落とし） が発生します。

この問題を解決し、専門手順や実行コードをオンデマンドで読み込むオープン標準規格が Agent Skills（agentskills.io） です。

本記事では、agentskills.io の公式仕様、中核となる 段階的開示（Progressive Disclosure） のアーキテクチャ、標準ディレクトリ構造、およびトークン効率と決定論的実行を両立する設計原則をまとめます。

段階的開示（Progressive Disclosure）のアーキテクチャ

Agent Skills の最大の特徴は、「必要な情報だけを、必要なタイミングで読み込む」 という 3 段階のライフサイクル設計にあります。

flowchart TD
 Phase1["1. 探索フェーズ（Discovery）<br>起動時：name と description のみ読み込み<br>（30〜100 トークン / スキル）"]
 -->|"ユーザーの指示が合致"| Phase2["2. 発動フェーズ（Triggering）<br>タスク発生時：SKILL.md 本文（手順書）を展開"]
 -->|"詳細仕様や自動化が必要"| Phase3["3. 実行フェーズ（Execution）<br>オンデマンド：scripts/ 実行、references/ 参照"]

1. 探索フェーズ（Discovery Phase）

エージェント起動時、インストールされている全スキルの SKILL.md から YAML フロントマター（name と description）のみ をインデックスとしてメモリに読み込みます。 1 スキルあたりわずか 30〜100 トークン程度しか消費しないため、数十〜数百個のスキルが存在してもコンテキスト上限を圧迫しません。

2. 発動フェーズ（Triggering Phase）

ユーザーのプロンプトを評価し、「このタスクにはあのスキルが必要だ」とエージェントが判断した瞬間に、該当する SKILL.md の 本文（Markdown 手順書） をコンテキストに展開します。

3. 実行フェーズ（Execution Phase）

スキルの手順書に従って作業を進める中で、追加のドキュメントが必要になった場合は references/ をピンポイントで参照し、自動化スクリプトが必要な場合は scripts/ を実行します。

Agent Skills の標準ディレクトリ構造

agentskills.io 仕様では、1 つのスキルを独立したフォルダとして構成します。

my-specialized-skill/
├── SKILL.md # 【必須 (Required)】メタデータ ＋ メイン手順書
├── scripts/ # 【任意 (Optional)】実行スクリプト（Python, Bash 等）
├── references/ # 【任意 (Optional)】詳細仕様書・スキーマ・参照資料
├── assets/ # 【任意 (Optional)】テンプレート・画像等の静的ファイル
└── evals/ # 【任意 (Optional)】スキルの動作検証用テストシナリオ

各サブディレクトリの役割

`SKILL.md`（必須）

スキルのエントリポイントです。YAML フロントマターと Markdown 本文で構成され、作業の大まかな流れや判断基準を記述します。

`references/`（任意：参照ドキュメント）

SKILL.md にすべて書ききれない 詳細な API 仕様書、エラーコード対応表、データスキーマ定義 などを格納します。

メリット: SKILL.md 自体をスリムに保ち、エージェントが「特定のエラーが発生したとき」「特定パラメータを調べるとき」だけ該当ファイルを読めるようにします。
記述例: SKILL.md 内に [エラー一覧](references/error_codes.md) のように相対パスでリンクを記載します。

`scripts/`（任意：実行コード）

エージェントがシェルから直接実行できるスクリプト（Bash, Python, Node.js 等）を配置します。

メリット: AI に複雑なワンライナーをアドホックに生成させるのではなく、テスト済みの決定論的なコードを実行させることで作業の再現性と安全性を担保します。

`assets/`（任意：静的アセット）

テンプレートファイル、設定の雛形、画像データなどを配置します。

`evals/`（任意：評価テスト）

スキルが想定通りに動作するかを検証するためのプロンプト例やテストケースを定義します。

`SKILL.md` の仕様と記述例

1. YAML フロントマターの仕様

SKILL.md の先頭には、探索フェーズで使われるメタデータを YAML 形式で定義します。

フィールド	必須 / 任意	型	説明
`name`	必須	`string`	スキルの一意な識別子（1〜64文字、小文字英数字・ハイフン）
`description`	必須	`string`	スキルの役割と発動条件（トリガー）を自然言語で記載（最大 1024 文字）
`license`	任意	`string`	ライセンス情報（MIT, Apache-2.0 等）
`compatibility`	任意	`string`	動作要件や前提環境（例: `Linux/macOS with Docker`）
`metadata`	任意	`object`	任意のカスタムキーバリューストア

IMPORTANT

description はトリガーの精度を左右する エージェントは description を読んでスキルの使用可否を判断します。「何をするか」だけでなく、「どんな状況・指示のときに使うべきか（Use this skill when…）」を明確に記述することが極めて重要です。

2. `SKILL.md` の実践例

---
name: db-migration
description: データベースのマイグレーション作成、適用、ロールバック、整合性確認を行う際に使用する。
compatibility: Linux / macOS, Docker 環境必須
---

# Database Migration Procedure

## 前提条件
- ローカルの PostgreSQL コンテナが起動していること。
- 詳細なテーブル定義は [スキーマ仕様](references/schema.md) を参照。

## 実行手順

1. **接続と状態確認**:
 ```bash
 ./scripts/check_connection.sh

マイグレーションの適用:
```
npm run migrate:up
```
整合性検証:
- 適用後、以下のテストを実行してエラーが出ないことを確認する。
```
npm run test:db
```
ロールバック手順（エラー発生時）:
- テストが失敗した場合は直ちにロールバックを実行する。
```
npm run migrate:down
```
- 失敗時のエラーコード詳細はトラブルシューティングを参照。


---

## Rules（`AGENTS.md`）と Skills の使い分け
 
エージェントのコンテキスト効率と動作精度を最大化するための役割分担です。

| 項目 | Rules (`AGENTS.md`) | Skills (`SKILL.md`) |
| :--- | :--- | :--- |
| **定義・役割** | プロジェクト全体の共通規約・制約・Guardrails | 特定タスクの手順定義・実行スクリプト・参照ドキュメント群 |
| **読み込みタイミング** | 毎ターンのプロンプトに常時注入 | タスク発生時（`description` が一致した際）のみオンデマンド展開 |
| **主な記述内容** | コーディング規約、禁止コマンド、全体アーキテクチャ | 実行コマンド手順、検証・ロールバックフロー、個別 API 仕様 |
| **トークン消費** | 常時消費（Context Bloat を防ぐため最小限に抑制） | 使用時のみ一時消費（タスク完了後は破棄可能） |

---

## Agent Plugins との関係性

**Agent Skills** と **Agent Plugins（1.0.0 共通規格）** は競合するものではなく、**包含関係** にあります。

- **Agent Skills（[agentskills.io](https://agentskills.io)）**:
 - 「1 つの手順書フォルダ」の単位規格（`SKILL.md`、`scripts/`、`references/`）。
- **Agent Plugins（[agentplugins.io](https://agentplugins.io)）**:
 - 複数の Agent Skills、MCP（外部ツール接続）、Rules（規約）を束ねて配布・インストール可能にする「統合パッケージ規格」。

Agent Plugins の仕様においても、スキルフォルダの内部構造は `agentskills.io` 規格がそのまま標準仕様として採用されています。

---

## スキル作成のベストプラクティス

1. **`SKILL.md` を短く保ち、詳細は `references/` へ逃がす**
 - `SKILL.md` に長文の API リファレンスを直書きせず、`references/` に個別ファイルとして分割する。
2. **決定論的なスクリプトは `scripts/` に置く**
 - 複雑な bash コマンドやデータ変換処理は、スクリプト化して同梱することで LLM の出力ブレを防ぐ。
3. **成功判定・ロールバック手順を必ず明記する**
 - コマンド実行後の成否判定基準（期待される出力文字列や終了コード）を記載し、自律的に完了判定を行えるようにする。
4. **テストケース（`evals/`）を整備してリグレッションを防ぐ**
 - スキルの発動条件（プロンプト例）と期待される出力シナリオを定義し、プロンプト変更やモデルアップデート時の精度劣化を防ぐ。

---

## まとめ

- **段階的開示（Progressive Disclosure）**: 探索時（メタデータのみ）➔ 発動時（本文展開）➔ 実行時（スクリプト・詳細仕様の参照）の 3 段階でトークン消費を最小化。
- **標準ディレクトリ構造**: `SKILL.md` を起点に `scripts/`、`references/`、`assets/`、`evals/` を整理し、ポータブルな運用手順書を構築。
- **エコシステムとの調和**: 常時規約（`AGENTS.md`）とタスク別手順（`Agent Skills`）を明確に分離し、統合パッケージ規格（`Agent Plugins`）とシームレスに連携。

> ※ 本記事の構成検討・技術仕様の検証・Hugo による静的ビルド検証・推敲は、AI コーディングエージェントとの自律協働ループによって執筆・検証されています。

---

## 参考リンク・情報ソース

- [Agent Skills 公式仕様 (agentskills.io)](https://agentskills.io)
- [Agent Plugins: The Open Packaging Standard (agent-plugins.org)](https://agent-plugins.org)
- [Lost in the Middle: How Language Models Use Long Contexts (Liu et al., 2023)](https://arxiv.org/abs/2307.03172)

AI指示ファイルの標準化と書き方：AGENTS.md の誕生・Linux Foundation 移管から各ツール比較まで

Wed, 19 Aug 2026 23:00:00 +0000

個人用メモ・備忘録

はじめに

AI コーディングエージェント（Google Antigravity、Cursor、GitHub Copilot、Claude Code 等）を実務で活用する際、プロジェクト固有のアーキテクチャ、ビルド・テスト手順、コーディング規約をいかに正確にエージェントへ伝えるかが重要になります。

当初はツールごとに独自の設定ファイルが乱立していましたが、現在はオープン標準仕様としての AGENTS.md を中心に共通化が進んでいます。

本記事では、AGENTS.md が生まれた背景と Linux Foundation 傘下の標準化団体への移管の経緯、各ツール固有の指示ファイルとの仕様比較、そして実用的な書き方の設計原則を整理します。

AGENTS.md の誕生とオープン標準化の経緯

AGENTS.md は、AI エージェントがリポジトリを自律的に理解して作業するための 「エージェントのための README（README for AI agents）」 として策定されたオープンな仕様です。

プロジェクトのルート / サブディレクトリ
├── README.md # 人間（開発者）向けのオンボーディング・概要説明
└── AGENTS.md # AI エージェント向けの機械可読な制約・実行コマンド・規約

1. 発祥：OpenAI による提唱（2025年8月）

2025 年 8 月、OpenAI が自社の Codex CLI 等に向けて提唱・導入したのが始まりです。

当時、AI ツールごとに設定ファイルが断片化しており、同じリポジトリであってもエディタやツールを切り替えるたびに別々の設定ファイルを保守する必要がありました。

Cursor: .cursorrules
GitHub Copilot: .github/copilot-instructions.md
Claude Code: CLAUDE.md

この乱立を解消し、「ベンダーニュートラルで、どの AI ツールでも共通して読める単一の指示フォーマット」として考案されたのが AGENTS.md です。

2. Linux Foundation（AAIF）への移管（2025年12月）

2025 年 12 月 9 日、中立なオープンスタンダードとして普及させるため、OpenAI、Anthropic、Block、Google、Microsoft、AWS、Cloudflare 等が参画して Linux Foundation 傘下に Agentic AI Foundation (AAIF) が設立されました。

この設立に伴い、主要各社から中核プロジェクトが寄贈されました。

AGENTS.md（OpenAI より寄贈）: エージェント向け共通指示フォーマット
Model Context Protocol (MCP)（Anthropic より寄贈）: ツール・外部データ連携プロトコル
goose（Block より寄贈）: ローカルファーストなオープンソース自律エージェント基盤

現在、AGENTS.md の仕様策定とガバナンスは特定の一企業ではなく、AAIF のコミュニティ主導で維持・管理されています（公式サイト：agents.md）。

指示ファイル仕様の比較

主要な AI コーディングツールにおける指示ファイルの配置と読み込み仕様の比較です。

ツール / 規格	設定ファイル	配置場所	主な特徴とスコープ
AGENTS.md (オープン標準)	`AGENTS.md`	ルート / 任意ディレクトリ	階層遡り（Walk-up）走査に対応。プレーン GFM で記述し、複数ツールで共通利用可能
GitHub Copilot	`copilot-instructions.md`	`.github/`	リポジトリ全体に適用。Chat、インライン提案、PR 要約等で参照
Cursor	`.cursorrules` `*.mdc`	ルート `.cursor/rules/`	フロントマターで `globs` を指定し、対象ファイル拡張子やパスごとにルールを動的適用可能
Claude Code	`CLAUDE.md`	ルート / サブディレクトリ	プロジェクトのビルド・テストコマンドやコード規約を自然言語で指定
Google Antigravity	`AGENTS.md` `GEMINI.md`	ルート / サブディレクトリ / `.agents/rules/`	`AGENTS.md` を標準サポート。Skills（手順書）や MCP（ツール接続）と分離して階層ロード

NOTE

現在の多くのツール（Antigravity、Cursor、Codex 等）は AGENTS.md をネイティブに解釈します。一部ツール（Claude Code 等）で専用ファイルを要求される環境では、AGENTS.md へのシンボリックリンクを作成して二重管理を防ぐ運用も一般的です。

各ツールの設定フォーマット

1. AGENTS.md（オープン標準）

GitHub Flavored Markdown (GFM) を用いたシンプルなテキストファイルです。複雑な YAML スキーマなどを強制せず、見出しやリスト構造で指示を記述します。

# Agent Guidelines

## プロジェクト構成
- フロントエンド: Next.js (App Router), Tailwind CSS
- バックエンド: Go (Echo), PostgreSQL

## コマンド
- ビルド: `npm run build`
- テスト: `npm test`
- リント: `npm run lint`

## コーディング規約
- コンポーネントは named export で定義する。
- 破壊的変更を伴うマイグレーション時は事前に確認を求める。

2. GitHub Copilot (`.github/copilot-instructions.md`)

リポジトリ全体に 1 枚で効かせる構成です。.github/ ディレクトリ配下に配置します。

# GitHub Copilot Instructions

## 技術スタック
- Node.js (v20+), TypeScript (v5+)

## コーディング規約
- `any` 型は使わず、型ガードと `unknown` を使う。
- 非同期処理は `try-catch` でエラーハンドリングする。

3. Cursor (`.cursorrules` / `.cursor/rules/*.mdc`)

.cursorrules はプロジェクト全体に適用されます。より細かい制御を行う場合、.cursor/rules/ 配下にフロントマター付きの .mdc ファイルを配置し、globs で対象ファイルを絞り込みます。

---
description: フロントエンド開発規約
globs: src/components/**/*.{ts,tsx}, src/app/**/*.{ts,tsx}
---

# Frontend Guidelines
- Server Components をデフォルトとし、必要な場合のみ `'use client'` を宣言する。
- アイコンは `lucide-react` を使う。

AGENTS.md を設計するときの原則

AGENTS.md は毎回のプロンプト（システムコンテキスト）に読み込まれるため、肥大化させると Context Bloat（トークン消費の増大） や、スタンフォード大等の研究 『Lost in the Middle』(Liu et al., 2023) で示された Attention Dilution（中盤に置かれた重要指示の希釈・見落とし） の原因になります。

TIP

常時ロード（AGENTS.md）とオンデマンド（Skills / ドキュメント）の分離

AGENTS.md に書くもの: 常時守るべきコーディング規約、必須ビルドコマンド、禁止事項（Guardrails）。
AGENTS.md に書かないもの: 長大なデプロイ手順、特定のライブラリの詳細 API 仕様、一時的なトラブルシューティング手順（これらは SKILL.md や個別ドキュメントに逃がし、必要な時だけ呼び出す）。

1. 「禁止」だけでなく「代替案」を明記する

AI は「〜〜するな」という否定形のみの指示だと、意図しない別の不適切なコードを生成することがあります。

❌ 悪い例: 「any 型を使うな」
⭕ 良い例: 「any 型は使わず、unknown 型と型ガード関数（Type Predicate）を使う」

2. モデルが既知の一般論は書かない

「読みやすいコードを書く」「保守性の高い設計にする」といった一般的な常識は LLM に元から備わっているため不要です。プロジェクト固有の命名規則やアーキテクチャの境界定義に絞り込みます。

3. 実行コマンドを正確に記載する

エージェントが自律的にテストやリントを実行できるよう、プロジェクトで実際に使用しているコマンド（引数や環境変数を含む）を明記します。

## コマンド
- 単体テスト: `npm run test:unit`
- E2Eテスト: `npx playwright test`
- 静的検証: `npm run type-check`

階層スコープ設計（Walk-up 継承とサブプロジェクトへの分散配置）

モノレポ構成や複数のパッケージ・マイクロサービスが同居するプロジェクトでは、各パッケージやディレクトリ内に個別の AGENTS.md ファイルを配置します。

エージェントはディレクトリツリー内で 最も近いファイルを自動的に読み込む ため、最も近いファイルが優先（オーバーライド・マージ）され、各サブプロジェクトはそれぞれに最適化された指示やビルドコマンドを配布できます。

my-project/
├── AGENTS.md # リポジトリ全体の共通規約（コミット規約、PR 作成ルール等）
├── packages/
│ ├── frontend/
│ │ └── AGENTS.md # React / Next.js 固有の規約とビルド・テストコマンド
│ └── backend/
│ └── AGENTS.md # Go / DB 固有の規約とマイグレーション手順

エージェントが packages/frontend/src/ 配下のファイルを編集する際、自身の階層から親階層へ向かって（Walk-up）順に探索し、直近の指示を優先しながらルートの共通ルールとマージして適用します。

NOTE

大規模リポジトリでの実例 ディレクトリごとに指示を分割するアプローチは、大規模なコードベースで標準的に実践されています。例えば、OpenAI のメインリポジトリには執筆時点で 88 個の AGENTS.md ファイル が配置されており、各モジュールやパッケージ単位でエージェントへの指示が細かく最適化されています。

Rules・Skills・MCP・Hooks の進化と標準化状況の違い

AI エージェントのカスタマイズ手法は、自然言語による指示（Rules）から、ツール連携（MCP）、手順書の段階的開示（Skills）、そしてプログラムによる強制介入（Hooks）へと段階的に進化してきました。

flowchart TD
 G0["【前史】チャット手動コピペ<br>（会話要約で指示が消える）"]
 -->|"リポジトリ内に常時配置"| G1["【第1世代】Rules / AGENTS.md<br>（全部盛りによるプロンプト肥大化）"]
 -->|"ツール接続と手順の分離・標準化"| G2["【第2世代】MCP & Skills<br>・MCP：ツール接続のAPI標準<br>・Skills：手順書のオンデマンド開示"]
 -->|"自然言語の確率的ブレを突破"| G3["【第3世代】Hooks（ライフサイクル介入）<br>プログラムで物理的に強制ブロック・後処理"]

1. 進化の歴史と「Hooks」が必要とされた理由

Rules（AGENTS.md）と Skills の限界: Rules や Skills は 自然言語による指示 であり、「危険なコマンドを実行するな」「直接 push するな」と指示しても、LLM の確率的な挙動（非決定性）により 100% 確実に防ぐことは困難でした。
Hooks のアプローチ（決定論的制御）: LLM の出力のブレに依存せず、エージェントの動作ループに スクリプトを割り込ませて実行を制御する仕組み（Git hooks と同様のアーキテクチャ） です。
- 実行前ゲート（PreToolUse）: コマンド実行直前にスクリプトが引数を検査し、危険な操作を物理的に遮断（deny）または強制確認（force_ask）。
- 実行後自動化（PostToolUse）: ファイル変更後に自動で prettier や eslint --fix を実行。
- 終了阻止（Stop）: テストが未完了または失敗している場合、エージェントの終了を差し止めてループを継続。

2. なぜ Hooks は標準化されていないのか？

AGENTS.md、MCP、Agent Skills が業界横断のオープン標準規格として共通化されているのに対し、Hooks は各 AI エージェントごとの独自実装（または未対応） に留まっています。

要素	標準化の状況	管理団体 / 共通仕様	役割と特徴
Rules (`AGENTS.md`)	標準化済み	Linux Foundation (AAIF)	どのエージェントでも読める行動規約（自然言語）
MCP	標準化済み	Linux Foundation (AAIF)	ツール・外部データ連携の標準プロトコル（API）
Skills (`SKILL.md`)	標準化済み	agentskills.io	特定タスクの手順定義・実行スクリプトのオンデマンド規格
Hooks (`hooks.json` 等)	⚠️ 非標準（各社独自）	なし（ツール固有機能）	プログラムによる強制実行・ゲート（決定論的制御）

Hooks の標準化が困難な主な理由は以下の 3 点です：

内部ループ設計の相違: 各エージェント（Antigravity、Cursor、Claude Code 等）で内部の処理ループ（プロンプト生成 → モデル呼出 → ツール実行 → 終了判定）の構造やイベント発火タイミングが異なる。
実行環境とセキュリティ境界の格差: ローカル OS のフルシェル権限で動く CLI と、閉じたクラウド・ブラウザ環境で動くエージェントでは、外部スクリプトを実行できるセキュリティモデルが根本的に異なる。
Interoperability Floor（相互運用の最低基準）の優先順位: Agent Plugins 1.0.0 等の統合パッケージ規格でも、まずは環境非依存で安全に共有できる Rules・Skills・MCP が中核となり、ホスト環境依存の強い Hooks はクライアント拡張領域として切り離されている。

TIP

実践における使い分けの方針

ポータブルに共有したい資産（規約、手順書、ツール連携）: オープン規格である AGENTS.md / Skills / MCP で記述する。
物理的な安全ガードや強制自動化（コマンド実行前の危険性チェック、保存後の自動 Lint 等）: Antigravity の hooks.json など、特定ツールの独自 Hooks 機能 で決定論的に制御する。

まとめ

発祥と標準化: AGENTS.md は 2025 年 8 月に OpenAI が提唱し、同年 12 月に Linux Foundation 傘下の Agentic AI Foundation (AAIF) へ移管されたオープン標準規格。
目的: ツール固有設定（.cursorrules, CLAUDE.md 等）の乱立を防ぎ、マルチエージェント環境で「エージェントのための README」として機能する。
設計の要点: 常時読み込みファイルであることを意識し、規約・制約・実行コマンドに絞り込んで記述する。詳細手順は Skills 等のオンデマンド機構に分離してコンテキストを軽量に保つ。
Hooks との住み分け: 自然言語による指示（Rules/Skills）と、プログラムによる決定論的制御（Hooks）の役割を理解し、ポータビリティと安全性を両立させる。

参考リンク・情報ソース

Agent Plugins の歴史とオープン標準化：Skills・MCP を統合する共通プラグイン規格

Wed, 19 Aug 2026 22:45:00 +0000

個人用メモ・備忘録

はじめに

AI コーディングエージェント（Antigravity、Cursor、GitHub Copilot、Claude Code 等）が急速に普及する中で、開発者が直面していた最大の課題は 「エージェント拡張機能の分断（Fragmentation）」 でした。

エージェント拡張機能（Agent Extensions）とは？

AI コーディングエージェントに対して、「新しい機能（外部ツール連携）」や「専門知識・実行能力（スキル）」を後から追加・カスタマイズする仕組み全般を指します。

エージェント拡張機能は、主に以下の 3 つの要素で構成されています。

Rules（行動指針・規約）
- 役割: 「このプロジェクトではこの方針・コーディング規約に従って」という指示。
- 代表例: AGENTS.md、.cursorrules、CLAUDE.md など。
MCP（Model Context Protocol / 外部ツール接続）
- 役割: AI が外部のデータベース、GitHub、API、クラウド環境等と安全にデータ送受信を行うための 「外部ツール・API 接続」。
- 代表例: GitHub MCP サーバー、PostgreSQL MCP サーバーなど。
Agent Skills（スキル / タスク実行ノウハウ）
- 役割: 特定のタスク（ビルド検証、テスト実行、マイグレーション等）を確実に実行するための 「手順書（SKILL.md）と実行スクリプト（scripts/）」。
- 代表例: SKILL.md（agentskills.io 規格）。

Agent Skills（スキル）とは？

AI エージェントに特定のタスク（ビルド検証、テスト実行、マイグレーション等）を確実に実行させるための 「手順書（SKILL.md）と実行用スクリプト（scripts/）をまとめた専用フォルダ」 です。

AI は手順書に従い、同梱されたスクリプトを自律的に呼び出して作業を行います。また、必要な時だけオンデマンドで読み込む（段階的開示） 仕組みのため、無駄なトークン消費を防ぎながら安全・確実にタスクを遂行できます。

従来はエージェント製品（クライアント）ごとに設定ファイルの配置場所や記述形式が異なるため、同じスキルや外部ツール連携を、Cursor 用、Copilot 用、Claude Code 用…と個別に書き直す必要がありました。

この問題を解決するため、2026 年 8 月 6 日、Vercel、OpenAI、Google、Microsoft、Anysphere（Cursor）、Amazon（AWS）らが共同で策定したオープン標準規格が「Agent Plugins 1.0.0」 です。

Agent Plugins とは？

Rules（規約）、MCP（ツール接続）、Skills（スキル）を 1 つのディレクトリにまとめて配布・利用できるようにした「エージェント向けプラグイン（拡張機能）」 です。

2026 年 8 月に策定された共通規格（1.0.0）に準拠することで、「Write once, run in any agent（一度作れば、どの AI エージェントでもそのまま動く）」という高いポータビリティを実現します。

本記事では、単一プロンプトから始まったエージェント拡張の歴史、Agent Plugins がオープン規格として標準化された背景、そして Skills（スキル）と MCP（外部ツール接続）を統合するプラグインの仕組みとディレクトリ構造を解説します。

エージェント拡張の歴史と「オープン標準」への進化

エージェントのカスタマイズ手法は、チャットプロンプトによる手動指示（前史）から単一ファイルのルール、そして業界横断のオープン標準規格へと進化してきました。

前史：チャットプロンプト時代（Prompt in Chat）

特徴: リポジトリに設定ファイルを置く仕組みがなく、毎回チャット欄の冒頭にコーディング規約や手順を手動でペーストしていた時代。
課題（会話履歴要約による指示の消滅）:
- 会話が 10〜20 ターンと進むと、コンテキスト上限に達したエージェントが過去の会話履歴を自動要約・圧縮（Compact）します。
- その際、「最初にプロンプトで伝えたはずの規約や前提条件」が要約によって削ぎ落とされ（Lossy Compression）、指示が効かなくなる という問題が生じていました。

第 1 世代：単一指示ファイル時代と AGENTS.md の登場（Prompt in Repo）

誕生の背景: 前史の「要約で指示が消える」問題を回避するため、「リポジトリ内に指示ファイルを置き、毎ターンのプロンプト（システムコンテキスト）に自動で丸ごと結合して LLM へ送信する」仕組みが生まれました。
初期の混乱と共通化（AGENTS.md）:
- 当初はエージェントごとに .cursorrules、copilot-instructions.md、CLAUDE.md と設定ファイルが乱立していました。
- この分断を解消するため、業界横断の共通仕様としてリポジトリ直下の AGENTS.md への標準化 が進み、多くのクライアント（Antigravity、Cursor、Copilot 等）がこれを共通ルールとして読み込むようになりました。
直面した「単一ファイル方式」の実用上の課題:
- ファイル名の統一には成功したものの、「1 つのファイルに規約・手順・API 仕様をすべて列挙するアーキテクチャ」そのものが持つ構造的な課題 が浮き彫りになりました。
- Context Bloat（プロンプト肥大化とコスト増）:
  - 常時ロードされる指示ファイル（固定費）に加えて、作業が進むにつれて会話履歴や読み込んだコード（変動費）が蓄積され、プロンプト全体が膨らんでコンテキスト上限を圧迫し、レイテンシが悪化する。
- Attention Dilution（注意の希釈と「中央ゾーンの指示無視」）:
  - Dilution（希釈・薄まり）。プロンプトは「① 文頭のシステム指示」「② 中盤の指示ファイルと会話履歴」「③ 文末の最新ユーザー入力」というサンドイッチ構造で LLM に送られます。
  - スタンフォード大等の研究 『Lost in the Middle』(Liu et al., 2023) が実証した通り、LLM は文頭と文末には強い注意（Attention）を払いますが、中央付近に位置するテキストへの Attention は著しく低下（U 字型カーブの谷底） します。
  - 指示ファイルが長大化したり会話履歴が伸びるほど、ファイル中盤に書かれた重要ルール（「テストを必ず書く」「特定記法を避ける」等）が中央のブラックホールゾーンに沈み込み、AI が指示を見落とす原因になっていました。

第 2 世代：機能パーツごとの標準化（MCP と Skills）とパッケージの分断

MCP（Model Context Protocol）による外部ツール接続の厳格な制御:
- スキルのような「自由なシェル・ターミナル実行」は自由度が高すぎる反面、AI が勝手なコマンドを叩くなど制御が難しいリスクがありました。
- 2024 年秋に Anthropic がオープンソース化した MCP は、「API で提供される、あらかじめ決められた正しい形式の安全な機能のみを呼び出す」 仕組みに制限することで、確実で安全なツール制御を標準化しました。
Agent Skills による手順定義の標準化（指示ファイルのスリム化＋段階的開示）:
- 指示ファイルのスリム化: 常時ロードする指示ファイル（AGENTS.md 等）には最小限の方針・規約と「どんなスキルがあるか」という目次（インデックス）のみを置き、プロンプトを常に軽量・高アテンションに保つ。
- 段階的開示（Progressive Disclosure）: 各作業の詳細手順や実行スクリプトは skills/<name>/ フォルダに独立させ、AI が「この作業が必要だ」と判断した瞬間だけノーカットの原本をオンデマンドで読み込む。要約（情報の欠落）に頼らず、完全な手順をロスレスで実行できる仕組みを確立（agentskills.io 規格）。
直面した新たな壁（パッケージ形式の分断）:
- ツール接続（MCP）と手順書（Skills）という個別パーツは揃ったものの、それらを 1 つに束ねて配布・インストールするための「共通パッケージ規格」が存在せず、各エージェント（Cursor、Copilot、Antigravity 等）で設定やフォルダ構造がバラバラでした。
- 同じ拡張機能であってもツールごとに別々のフォーマットで設定・保守する必要があり、チーム内での共有や運用の摩擦となっていました。

第 3 世代：Agent Plugins 1.0.0 オープン標準の成立（2026 年 8 月）

発起・共同策定:
- Vercel が主導し、OpenAI、Google（Core Maintainer）、Microsoft、Anysphere（Cursor）、Amazon（AWS） が技術運営委員会（TSC: Technical Steering Committee）を結成。
目的:
- 「Write once, run in any agent（一度書けば、どの AI エージェントでもそのまま動く）」
- プラットフォーム固有の独自仕様を排し、Rules（規約）、MCP（ツール接続）、Skills（スキル）を 1 つの統一ディレクトリ構造（plugin.json）で管理・配布できるように標準化。
対応状況とエコシステム:
- 統合パッケージ直接対応: Cursor、VS Code（GitHub Copilot / 各種 Agent 拡張）、Google Antigravity、ChatGPT / Codex、Kiro など TSC 参加企業や賛同クライアントを中心に共通化が進展。
- 個別パーツでの互換性: Claude Code や Aider などの独自 CLI は、統合プラグイン（plugin.json）の直接ロードではなく、自社のディレクトリ構造（CLAUDE.md や .claude/mcp.json）を通じて MCP やルールを個別に配置・利用する設計を維持しています。

標準規格の関係性（Rules・Skills・MCP）

Agent Plugins はゼロから作られたものではなく、先行して普及していた 2 つのオープン標準「MCP」と「Agent Skills」を包括する「共通プラグイン規格」 として位置づけられています。

MCP (Model Context Protocol):
- Anthropic が 2024 年秋に策定したオープン規格。エージェントが外部世界（DB、GitHub、クラウド）と安全にやり取りするための 「外部ツール・API 接続」 を提供します。
Agent Skills (agentskills.io):
- 2025 年から広まった手順書規格。エージェントが特定タスクを確実に遂行するための 「手順書（SKILL.md）と実行スクリプト（scripts/）」 を提供します。
Agent Plugins (agent-plugins.org):
- 2026 年 8 月に策定された統合規格。上記 2 つの先行規格（MCP と Skills）および Rules を 1 つのディレクトリに束ね、どのエージェントでもそのまま動くようにする 「共通プラグイン（配布・利用単位）」 です。

Agent Plugins のディレクトリ構造とマニフェスト仕様

Agent Plugins 1.0.0 では、相互運用性を保証するために明確なディレクトリレイアウトとマニフェスト（plugin.json）が定義されています。

plugins/<plugin_name>/
├── plugin.json # 【必須】プラグインの定義・名札（必須マニフェスト）
├── skills/ # 【任意】手順書を含める場合に配置（Agent Skills 規格）
│ └── <skill_name>/
│ ├── SKILL.md # 【必須】スキルの手順書（フロントマター ＋ 本文）
│ └── scripts/ # 【任意】自動化スクリプトを含める場合に配置
└── mcp.json # 【任意】外部ツール・API 連携を含める場合に配置

`plugin.json` の仕様

マニフェスト（Manifest / plugin.json）とは？

ソフトウェアやプラグインの 「名札・基本プロフィール（メタデータ）を記した定義ファイル」 のことです。

Node.js における package.json や、Chrome 拡張機能の manifest.json と同じ役割を果たします。エージェントはまずこのファイルを読むことで、「このプラグインの名前は何か」「どんな目的で作られたのか」「どのバージョンか」を一目で認識し、安全にロードします。

プラグインのルートに配置するマニフェストファイルです。エージェント間の互換性を保つため、スキーマ定義に基づいた厳格なメタデータが記述されます。

{
 "$schema": "https://agentplugins.io/schemas/v1/plugin.json",
 "name": "devops-toolkit",
 "description": "インフラデプロイ手順、DBマイグレーション、および Cloud MCP 連携を提供するプラグイン",
 "version": "1.0.0",
 "disabled": false
}

JSON スキーマ（$schema）とは？

JSON ファイルに 「必須項目やデータ型のルールブック（設計図）」を適用するための仕組み です。

VS Code や Cursor 等のモダンなエディタにはスキーマエンジンが標準内蔵されているため、特別なプラグインの追加や事前設定は一切不要 です。冒頭に "$schema": "https://..." と 1 行記述しておくだけで、エディタが自動でネットからルールブックを読み込み、誰の PC 環境でも即座に以下の支援が有効になります。

エディタの入力補完: Ctrl + Space で、次に書くべきキー（description や version 等）が自動でサジェストされます。
タイポ（スペルミス）の即時検知: キー名を打ち間違えたり、必須項目を書き忘れた場合にエディタが赤波線で警告してくれます。
エージェントによる整合性検証: AI エージェントがプラグインを読み込む際、壊れた不正な設定ファイルを自動で検知・除外できます。

$schema: 公式の Agent Plugins JSON スキーマ URI（エディタでの入力補完やバリデーションを有効化）
name: プラグインの一意な識別名
description: エージェントがプラグインの目的を理解するための自然言語テキスト
version: セマンティックバージョニング（SemVer）に準拠したバージョン表記

コア構成要素 ①：Agent Skills（手順書と実行スクリプト）

Agent Skills 規格（agentskills.io） に準拠した手順書（Runbook）です。

エージェント起動時は SKILL.md のフロントマター（name と description）のみを読み込み、ユーザーの指示が合致した瞬間だけ本文がコンテキストへ注入される 「Progressive Disclosure（段階的開示）」 により、トークン消費を抑えながら確実な手順実行を実現します。

---
name: db-migration
description: データベースの新規マイグレーション作成、適用、および整合性チェックを行う際に使用する。
---

# Database Migration Procedure

## 前提条件
- Docker コンテナでローカル DB が起動していること。

## 実行手順
1. `./scripts/validate.sh` を実行して接続を確認する。
2. `npm run migrate:up` を実行する。
3. `npm run test:db` で整合性を確認する。
4. エラーが発生した場合は `npm run migrate:down` でロールバックする。

コア構成要素 ②：MCP（外部ツール・API 接続）

MCP は、自由すぎるシェル実行による暴走やミスを防ぎ、「API で提供される、あらかじめ許可された特定の機能のみ」を決められた正しい形式で安全に呼び出せるようにした ツール接続規格です。

プラグイン内の mcp.json（または mcp_config.json）で宣言された MCP サーバーは、プラグインが有効化された際にクライアントによって自動起動・接続されます。

{
 "mcpServers": {
 "github": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-github"],
 "env": {
 "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GITHUB_TOKEN}"
 }
 },
 "db-inspect": {
 "command": "uvx",
 "args": ["mcp-server-sqlite", "--db-path", "./data/dev.db"]
 }
 }
}

環境変数によるシークレット管理

プラグインを Git でチーム共有したり外部配布した際に API キーや機密情報の漏洩を防ぐため、トークンやパスワードは設定ファイルに直接記述せず、必ず ${env:VAR_NAME} 形式で各ユーザーの実行環境から動的に注入します。

プラグインの配置と共有モデル

Agent Plugins 1.0.0 は「プラグイン内部のフォーマット」を統一する相互運用性の最低基準（Interoperability Floor：互換性を保つための共通の土台） であり、配置場所やインストール・管理方法は各エージェント（クライアント）の仕様 に委ねられています。

主な配置・共有の形態：

リポジトリ内共有: 各エージェントがサポートするプロジェクト内ディレクトリに配置し、Git でチームメンバーと共有。
- 例: .agents/plugins/<name>/（Antigravity、Cursor、Copilot 等で共通してサポートされるデファクト配置）
- 例: .gemini/plugins/<name>/（Antigravity 固有）、.vscode/plugins/<name>/（VS Code / Copilot 固有）
個人環境でのグローバル利用: 各ツールのグローバル設定ディレクトリ（例: ~/.gemini/antigravity-cli/plugins/ など）に配置し、全プロジェクトで共通して利用。
外部配布: Git リポジトリや将来的なパッケージレジストリを通じた OSS プラグインの共有。

実践例：チーム共通の「リリース自動化プラグイン」

オープン標準の Agent Plugins を使えば、Skills（手順・スクリプト）と MCP（外部ツール接続）が 1 まとまりになった再利用可能な拡張機能をシンプルに構築できます。

plugins/release-toolkit/
├── plugin.json # プラグイン定義（バージョン・説明）
├── skills/
│ └── prepare-release/
│ ├── SKILL.md # リリース前テスト・CHANGELOG 生成手順
│ └── scripts/
│ └── check-diff.sh
└── mcp.json # GitHub MCP（PR 作成・タグ打ちツール）

1. プラグイン定義 (`plugin.json`)

{
 "$schema": "https://agentplugins.io/schemas/v1/plugin.json",
 "name": "release-toolkit",
 "description": "バージョン検証、CHANGELOG 生成、および GitHub リリース PR 発行を自動化するプラグイン",
 "version": "1.0.0"
}

2. リリース手順書 (`skills/prepare-release/SKILL.md`)

---
name: prepare-release
description: リリース前の差分検証、テスト実行、CHANGELOG 更新を行い、リリース PR を準備する際に使用する。
---

# Release Preparation Procedure

## 実行手順
1. `./scripts/check-diff.sh` を実行し、未コミットの差分や型エラーがないか検証する。
2. `npm test` を実行して全テストが通過することを確認する。
3. 前回タグからのコミットログを抽出し、`CHANGELOG.md` を更新する。
4. GitHub MCP の `create_pull_request` ツールを呼び出し、「Release vX.Y.Z」の PR を作成する。

3. 実行スクリプト (`skills/prepare-release/scripts/check-diff.sh`)

#!/usr/bin/env bash
set -euo pipefail

echo "=== リリース前検証を開始 ==="

# 1. 未コミット差分の確認
if [ -n "$(git status --porcelain)" ]; then
 echo "Error: 作業ツリーに未コミットの変更が存在します。" >&2
 exit 1
fi

# 2. 型チェックの実行
echo "TypeScript 型チェック中..."
npm run typecheck

echo "✓ 検証完了: リリース準備が可能です。"

4. 外部ツール接続 (`mcp.json`)

{
 "mcpServers": {
 "github": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-github"],
 "env": {
 "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GITHUB_TOKEN}"
 }
 }
 }
}

Skills: リリース前チェック手順書をオンデマンドで展開し、差分確認スクリプトを実行。
MCP: GitHub MCP ツールを安全に呼び出してリリース PR を発行。

Agent Plugins の今後の展望

バージョン 1.0.0 の策定によって「共通のディレクトリ構造」という最低限の土台（Interoperability Floor）が確立されました。今後は以下のような領域でのエコシステムの発展が期待されています。

パッケージレジストリと導入の自動化:
- 現在は Git リポジトリやローカルディレクトリでの配置が中心ですが、今後は npm や Homebrew のように agent install <plugin-name> といったコマンドで即座にプラグインを導入・更新できる公式レジストリの整備が進む見込みです。
セキュリティと実行パーミッションの標準化:
- プラグインに同梱されたスクリプトや MCP ツールがホスト環境を安全に操作できるよう、サンドボックス実行やアクセス権限（パーミッション承認）の共通モデル策定が議論されています。
エコシステム全体の相互運用性の深化:
- 現在は独自ディレクトリ構成をとっている CLI ツールやチャットプラットフォームも含め、業界全体でのプラグイン互換性のさらなる拡大が見込まれます。

まとめ

Agent Plugins 1.0.0 は、独自機能の乱立から、業界横断のオープン標準（Open Specification）への進化 を象徴する規格です。

誕生の必然: チャットプロンプト（前史）➔ 単一指示ファイル（第1世代）➔ MCP/Skills による機能分離（第2世代）➔ 共通プラグイン規格（第3世代）
主要各社による共同策定: Vercel、OpenAI、Google、Microsoft、Cursor、AWS らが手を組み、ベンダー中立なオープン仕様として標準化
2 大オープン標準の統合: 「MCP（安全なツール接続）」＋「Skills（オンデマンド手順書）」を 1 つの統一ディレクトリに集約

これにより、一度プラグインを作成すれば、Cursor、VS Code、Google Antigravity、ChatGPT など対応クライアントを選ばずに同一の高度なエージェントワークフローを展開できるようになりました。

参考リンク・情報ソース

公式仕様・規格ハブ

学術論文（コンテキスト特性・Attention 希釈）

Lost in the Middle: How Language Models Use Long Contexts (Liu et al., 2023 / Stanford University, UC Berkeley)

Antigravity CLI で実践する自律実行ループ設計（ループエンジニアリング）

Mon, 17 Aug 2026 02:40:00 +0000

個人用メモ・備忘録

ループエンジニアリングとは

Google の Addy Osmani 氏は、エッセイ『Loop Engineering』(2026-06-07) の中で、ループエンジニアリングを次のように定義しています。

Claude Code の開発を率いるボリス・チェルニー（Boris Cherny）氏も、次のように語っています。

NOTE

プロンプトエンジニアリングから「ループエンジニアリング」への転換

旧来のプロンプトエンジニアリング: 人間が AI と対話しながら 1 問 1 答で手動調整するアプローチ。人間がプロンプトを打ち、出力を目視確認するため、人間の思考速度と確認作業が最大のボトルネックになっていました。
ループエンジニアリング: AI 自身がツールを実行し、テスト結果から合否を自己判定して自走する**「自動フィードバックの仕組み（自律ループ）」** を設計・構築するアプローチ。人間の役割は「指示係」から「ループの設計者」へとシフトします。

自律ループを支える基本要素

Addy Osmani 氏は自律ループを成立させるための 5つの基本要素（Primitives） と 1つの外部メモリ（Memory） を整理しています。

構成要素	ループ内での役割	具体的な実装例
1. Automations（自動化）	定期実行・タスクの探索とトリガー	定期監視（`/schedule`）、ゴール駆動実行（`/plan`）
2. Worktrees（並行隔離）	エージェント作業の衝突を防ぐ環境分離	`git worktree`、独立ブランチでの作業
3. Skills（スキル）	特定タスクに必要な手順書・知識のオンデマンド提供	Agent Skills（`SKILL.md` / Runbook）
4. Plugins / Connectors	外部ツールや API との接続	MCP（GitHub MCP、各種外部ツール連携）
5. Sub-agents（サブエージェント）	実装担当（Maker）と検査担当（Checker）の分離	調査用・レビュー用のサブエージェント分割
+ Memory（外部記憶）	セッションを跨いだ知見・進捗の永続化	`Learnings.md` や `AGENTS.md`

特に重要なのが 「Memory（外部記憶）」 です。

Addy 氏が 「The agent forgets, the repo doesn’t（エージェントは忘れるが、リポジトリは忘れない）」 と述べている通り、 LLM のコンテキストウィンドウの外側（リポジトリ内の Markdown 等）に状態やルールを逃がして引き継ぐことで、初めてセッションが途切れても継続する自律ループが完成します。

5+1 の部品が組み合わさることで生まれる「3 つの核心要件」

上記の「5+1 の要素」は、ループを組み立てるための 「構成部品（Primitives）」 です。これらが単体で存在するだけでは自律ループは回らず、適切に組み合わさることで初めて後述する 「3 つの核心要件（メカニズム）」 が満たされます。

① フィードバックの永続化と自己進化 ◀ Memory ＋ Skills（知見の蓄積と定型手順のライブラリ化）
② 人間の介入待ちを排除した自律走行 ◀ Automations ＋ Worktrees（環境隔離というハーネスがあるからこそ安全に自走できる）
③ AI 自身に合否を判定させる客観的ロジック ◀ Plugins (MCP) ＋ Sub-agents（検証ツールの自動実行とレビュー分掌）

ループエンジニアリングを成立させる 3 つの核心要件

ループエンジニアリングの真髄は、これまで人間が頭を使い、目視で行っていた 「確認・合否判定・やり直し指示（フィードバック）」を、可能な限り AI と判定ロジックの仕組みに委ねること にあります。

ただし、AI に自律的な行動を委ねるには、大前提として 「ハーネス（Harness）」 ── すなわち Docker コンテナや Git ブランチ分離等による 影響の隔離（Sandboxing）と可逆性（Reversibility）を保証する安全な実行環境 ── が整備されている必要があります。このハーネスという土台の上で、以下の 3 つの本質的な足場が不可欠です。

1. フィードバックの永続化と自己進化（外部記憶）

エージェントのコンテキスト肥大化を防ぎつつ、過去の失敗やプロジェクト固有ノウハウを引き継ぐため、外部記憶を 「常時ロード層」 と 「オンデマンド参照・自己進化層」 の 2 つに分離します。

TIP

単一指示ファイルの肥大化が引き起こす 2 つの技術的ボトルネック AGENTS.md や CLAUDE.md に過去のエラー対策をすべて書き足していくアプローチには、以下の欠陥があります。

Context Bloat（トークン消費の爆発）: 大量の知見が毎ターン送信され、何もしなくても会話開始時点で大量の入力トークンを消費し、レイテンシと API コストが急増します。
Attention Dilution / “Lost in the Middle” 現象（指示の希釈）: スタンフォード大等の研究 『Lost in the Middle』(Liu et al., 2023) の通り、プロンプトが長大化・ノイズ化するほど重要指示に対する注意が希釈され、最重要ルールの遵守率が低下します。

2 層分離設計の動作メカニズム

この課題を解決するのが、AGENTS.md（常時ロード層） と Learnings.md（オンデマンド参照・自己進化層） の 2 層構造です。

TIP

常時ロード層 vs オンデマンド参照層の仕組み

AGENTS.md（常時強制ロード）: エージェントツールの基盤仕様として、毎ターンのプロンプトに無条件で自動注入されます。
Learnings.md（オンデマンド参照）: システムが全行を自動注入することはありません。AGENTS.md のポインタ指示に従い、エージェントが必要な時だけツール（view_file や grep_search）で能動的に検索・読み込みを行う通常ファイルとして扱われます。

「ポインタ（参照）」としての AGENTS.md 単に Learnings.md をリポジトリに置いただけでは、エージェントはそのファイルの存在に気づかない可能性があります。そこで、常時ロードされる AGENTS.md に以下のような ポインタ（索引指示） を 1 行だけ記述します。

- **知見の参照**: 詳細な技術仕様や過去のトラブルシューティングは Learnings.md を参照する。

これにより、プログラミングにおける「ポインタ・参照渡し」と同じ構造が作られます。

エージェント起動時: コンテキストには軽量な AGENTS.md（数十行）のみが注入され、トークン消費を最小限に抑えます。エージェントは「困ったときは Learnings.md という外部ナレッジがある」というポインタ情報のみを把握しています。
タスク実行時（オンデマンド参照）: ビルドエラーや環境固有の仕様に直面した際、エージェントは AGENTS.md のポインタ指示に従い、ツール経由で Learnings.md をピンポイントで検索・読み込みます。
タスク完了時（自己進化）: 新しいバグ修正や仕様の発見があった場合、エージェント自身が Learnings.md の末尾に知見を自律的に追記・更新します。

TIP

知見のライブラリ化（Skills への昇格） Learnings.md に蓄積された断片的な教訓のうち、定型化・複雑化したワークフローは Skills（.agents/skills/*/SKILL.md） へ昇格させます。スキルは「名前と概要（メタデータ）」のみを軽量保持し、該当タスク実行時のみ全文がオンデマンド注入されるため、トークンを浪費することなく高度な専門手順をライブラリ化できます。

NOTE

外部記憶アーキテクチャの学術的ルーツと実務背景

Reflexion (Shinn et al., 2023 / NeurIPS 2023): タスク失敗時に自然言語で自己反省（Self-reflection）を行い、言語的メモリ（Verbal Memory）に蓄積して次回試行時に参照させることで、同一エラーの再発を防ぐ手法を実証。
Voyager (Wang et al., 2023 / スタンフォード大・NVIDIA 等): Minecraft 自律エージェントにおいて、獲得したスキルや手順をディスク上の Skill Library に保存し、必要に応じて動的に検索・再利用する自律学習モデルを確立。
実務への定着: 障害対応の事後検証（Post-mortem）から得られる「Key Learnings」文化と、Addy Osmani 氏の「Memory Primitive（The agent forgets, the repo doesn’t）」が接続し、2 層構造が自律ループの基本設計として定着。

2. 人間の介入待ちを排除した自律走行（ノンブロッキング権限）

Automations（ゴール駆動実行や定期監視） によってエージェントを自走させる際、コマンドを実行するたびに対話型の承認プロンプト（Confirmation）を挟むと、自律ループがブロックされて人間が再び作業のボトルネックになります。

たとえば、AI がコードを修正した後に hugo --cleanDestinationDir で検証しようとするたびに「このコマンドを実行してよいですか？ [y/N]」と聞かれる状況を想像してみてください。人間が承認ボタンを押すまで AI は完全に停止し、自己修復ループは事実上崩壊します。

日常的に使用するテスト・ビルド・Git コマンドを事前許可（Allowlist 化）し、「人間の確認待ちによるループ停止」を排除 して AI を止まらずに自走させます。

WARNING

「言葉による確認スキップ」と「物理サンドボックス」の決定的な違い 単にプロンプトで「確認してこないで勝手に進めて」と指示したり、全権限を無制限に解放（--dangerously-skip-permissions）するのは、セーフティネットのない危険なノールック運転（YOLO） に過ぎません。

また、「Git があればコードを壊されても戻せる」「テストコマンドだけ許可（Allowlist）すれば安全」という考えにも落とし穴があります。たとえば npm test や pytest を許可していたとしても、サンドボックスがないホスト環境ではテストプロセス自体がホスト OS の権限で動くため、テストスクリプト内でホスト側の重要ファイルを削除・破壊されるリスクを防げません。

Git: 「リポジトリ内のコードの可逆性」しか保証しない
CLI の Allowlist: アプリケーション層の制約に過ぎず、プロセス内部の挙動は防げない
サンドボックス（Docker / WSL2 等）: OS カーネルレベルでホストからプロセスを物理隔離する

だからこそ、自律ループの権限を解放するには、「最悪壊れてもホストに影響せず、即座に捨てて再構築できる物理サンドボックス（ハーネス）」 が絶対の大前提となります。

3. AI 自身に合否を判定させる客観的ロジック（自動検証）

人間が画面に張り付いて良し悪しを目視チェックするのをやめ、Plugins / MCP（ツール実行） を通じて「自動テストやビルドスクリプト」を AI 自身に実行させ、合否を自己判断・自己修復させます。

また、複雑なタスクにおいては Sub-agents（サブエージェント） を活用し、実装担当（Maker）と検査・レビュー担当（Checker）を分掌させることで、人間の代わりに機械的で客観的な二重判定ループを自律的に回すことが可能になります。

TIP

Fast Observability（高速な自動検証）を成立させる 4 要件

5 秒以内の高速実行: 検証が遅いと自己修復ループ全体の回転が鈍化します。
厳格な終了コード（Exit Code 0/1）: 成功/失敗を AI が機械的に判定できるようにします。
明瞭な標準エラー出力（stderr）: エラー行・スタックトレースから AI が自力で原因特定できるようにします。
知見の正確性フィルター: 自動テストをパスして再現性が証明された解決策だけを Learnings.md に蓄積します。

Antigravity CLIにおけるループエンジニアリングの実践

これまで解説した 「3 つの核心要件」 を、Antigravity CLI（agy）の各機能（5+1 の構成要素）を使って具体的にどう設定・実装するかを解説します。

3 つの核心要件と Antigravity CLI 機能の実装対応

核心要件	Antigravity CLI での実装要素（5+1）	具体的なツールと設定ファイル
1. フィードバックの永続化と自己進化	Memory ＋ Skills	`AGENTS.md`、`Learnings.md`、`.agents/skills/*/SKILL.md`
2. 人間の介入待ちを排除した自律走行	Permissions ＋ Worktrees ＋ Automations	`settings.json`（権限設定）、`Workspace: "branch"`、`/plan`、`/schedule`
3. AI 自身に合否を判定させる客観的ロジック	Fast Observability ＋ Plugins ＋ Sub-agents	自動検証コマンド、GitHub MCP、Checker サブエージェント

具体的な環境設定

当ブログ環境における、3 つの核心要件の具体的なセットアップ手順です。

1. フィードバックの永続化：外部記憶とスキル（Memory ＋ Skills）

外部記憶（AGENTS.md / Learnings.md）: プロジェクト直下の AGENTS.md に、基本方針と Learnings.md に対する参照・自己進化（追記・週次整理）ルールを記述します。

# 自律動作ポリシー
- **自律完遂**: 軽微な判断やエラー自己修復は質問を挟まず自律的に進める。破壊的変更（ファイル破棄や強制プッシュ等）のみ確認を行う。
- **知見の参照**: 詳細な技術仕様や過去のトラブルシューティングは `Learnings.md` を参照する。
- **自己進化**:
 - 新たなトラブル解決や環境固有の仕様・ノウハウを発見した際は、自発的に `Learnings.md`（および必要に応じて本 `AGENTS.md`）へ要約追記してタスクを完了する。
 - `Learnings.md` の最終整理日から1週間以上経過している場合、内容を棚卸し・整理して日付を当日の日付に更新する。

スキルのライブラリ化（.agents/skills/*/SKILL.md）: 定型化された複雑なワークフロー（例：記事の新規作成手順、画像生成ルール等）は、ディレクトリごとに SKILL.md として切り出し、必要な時だけオンデマンドでエージェントに読み込ませます。

2. 自律走行の解放：権限・環境隔離・自動化（Permissions ＋ Worktrees ＋ Automations）

ノンブロッキング権限（settings.json）: 日常的に使用する検証コマンドや Git コマンドを ~/.gemini/antigravity-cli/settings.json の permissions.allow に登録し、確認プロンプトによるループ停止を排除します。

{
 "permissions": {
 "allow": [
 "command(hugo*)",
 "command(npm test*)",
 "command(git status)",
 "command(git diff)",
 "command(git log)",
 "command(git commit*)"
 ]
 }
}

作業環境の隔離（Worktrees / Workspace: "branch"）: サブエージェント呼び出し時に Workspace: "branch" を指定し、Git のブランチ・作業ツリーを完全に分離。メイン環境を破壊するリスクを排除します。
自走トリガー（/plan や /schedule、非対話モード -p）: ゴール駆動実行（/plan）や定期監視（/schedule）、CI連携（agy -p）により、人間の手動入力を介さずに自走ループを回します。

3. 客観的判定ロジック：自動検証・ツール・分掌（Fast Observability ＋ Plugins ＋ Sub-agents）

高速な自動検証（Fast Observability）: エージェントが自己修復ループを回すための「客観的な合否判定コマンド」を用意します。当ブログでは、出力先（public/）の過去キャッシュを完全消去した上で、全ページのメタデータ・Markdown 構文・テンプレート（Sass/i18n）の整合性をゼロから 1 秒台で検証するコマンドを定義しています。1 箇所でも不整合があれば Exit Code 1 と明確なエラー行（stderr）が出力されるため、AI が自力で即座に自己修正できます。

# 出力先をクリーンにして全ページの構文・アセット整合性を1秒で機械判定（Exit Code 0/1）
hugo --cleanDestinationDir

外部ツール連携（MCP サーバー / Plugins）: GitHub MCP などの MCP サーバー（Model Context Protocol） を連携させ、リモートリポジトリの Issue 取得、PR 作成、ファイル操作をエージェントに直接実行させます。
レビュー分掌（Sub-agents による Maker / Checker 分離）: コードを実装する「Maker エージェント」と、テスト・レビューを担当する「Checker サブエージェント」を invoke_subagent で分担させ、客観的な二重判定ループを自律実行させます。

他のエージェントツールへの普遍的応用

本記事で解説した 3 大核心要件（2 層外部記憶・ノンブロッキング自走・客観的自動検証）は、Antigravity CLI に限らず、Claude Code や Cursor などの主要なコーディングエージェント環境にもそのまま応用できる普遍的な設計パターンです。

核心要件・設計要素	Antigravity CLI	Claude Code	Cursor
常時ロード層	`AGENTS.md`	`CLAUDE.md`	`.cursor/rules/*.mdc`
オンデマンド外部記憶	`Learnings.md`	`Learnings.md`	`Learnings.md` / Notepads
自走コマンド	`/plan`, `/schedule`	`claude -p` / `--dangerously-skip-permissions`	Agent Mode（Yolo モード）
高速自動検証	ターミナルコマンド	ターミナルコマンド	Terminal Tool / Task Runner

ループエンジニアリングにおける現在の課題

ループエンジニアリングは現在進行形で発展しているアプローチであり、実務で運用する上では以下のような課題や限界も存在します。

1. ハーネス（物理サンドボックス）の必須性と非隔離環境でのトレードオフ

AI は確率的・非決定的に動作するため、プロンプトや CLI ツールの設定（ソフトウェア制御）だけで予期せぬ挙動を 100% 防ぐことは原理的に不可能です。そのため、自律ループの構築には OS カーネルレベルでプロセスを封じ込める 「物理サンドボックス（Docker、WSL2、使い捨て VM 等）」が不可欠な前提 となります。

しかし、実務環境（特にコンテナ導入に制約がある Windows ホスト等）において物理サンドボックスを用意できない場合、「安全性と自律性の厳しいトレードオフ」 に直面します。

自律性を追求する場合（サンドボックスが必須）: ホスト OS を破壊するリスクを排除するため、最低限の隔離環境（WSL2 や Windows Sandbox、独立 VM）を用意してその中でエージェントを動かす必要があります。
物理隔離がない場合（安全のために自律性を制限）: Allowlist による自動実行はホスト破壊のリスクを伴うため、コマンド実行のたびに人間が目視確認する 「Human in the loop の多発（自律性の犠牲）」を受け入れるのがセキュリティ上極めて正当な判断 となります。

また、Docker 等でサンドボックスを構築した場合でも、ホストマウントされたファイルの誤削除、API トークンの漏洩、リモート Git の誤プッシュなど「絶対的な安全」の保証は困難です。安全性を過信せず、破壊的変更への人間確認を残すなどの多重防御（Defense in Depth）が求められます。

2. 良質な自動検証（テスト）の整備・保守コスト

AI が自力で合否を判定するためには、「5 秒以内で Exit Code 0/1 を厳格に返す自動テストやビルドスクリプト」が必要です。このテスト環境自体の作成やメンテナンスに人間の工数がかかり、テストが甘いとバグの見逃し（偽陽性）が発生します。

3. トークン消費と API コストの増大

AI が自律ループの中で試行錯誤（エラー検知 ⇄ コード修正 ⇄ 再検証）を何度も繰り返すと、1 つのタスクで数十万トークンを短時間で消費し、API コストやレート制限（Quota）を圧迫するリスクがあります。

4. 誤学習・間違った知見の固定化（Toxic Learning）

たまたま動いただけの一時的な回避策や誤った解釈を Learnings.md に蓄積してしまうと、次回以降の全セッションで AI がその誤ったノウハウに縛られ続ける危険性があります。

5. テストハック（局所最適化）のリスク

AI が「目の前のテストを通すこと」だけに集中するあまり、全体の可読性やアーキテクチャ設計を犠牲にしたトリッキーなコード（テストハック）を書いてしまう場合があります。

それでもループエンジニアリングに進まざるを得ない理由

これほど多くの課題や初期投資（ハーネス・テストの整備）が必要であるにもかかわらず、なぜ開発の最前線がループエンジニアリングへと向かっているのでしょうか？

その理由は、「人間が間に入ってプロンプトを入力し、目視確認する 1 問 1 答の運用では、スループットに構造的な限界があるため」 です。

人間のタイピングと目視速度が「開発速度のボトルネック」になる: AI のモデル知能が向上しても、人間が指示を入力し、出力を確認して修正を指示している限り、全体の生産性は「人間の手動介入速度」で頭打ちになります。
手動確認による認知負荷の蓄積: AI の出力コードを人間が毎回目で追い、不備を見つけてプロンプトで修正させる作業は認知負荷が高く、スケールしません。
初期投資の先にあるスループットの向上: ハーネスやテストの整備にはコストがかかりますが、一度「自律ループ」を構築すれば、人間が他の作業を進めている間に AI が自走してタスクを完走する高いスループットが得られます。

これは、かつて CI/CD（継続的インテグレーション・自動テスト） が登場した際、「テストを書くのが面倒」「CI の構築コストがかかる」と言われながらも、手動ビルドの時代には二度と戻れなくなった歴史の必然と同じ構造です。

まとめ：安全なハーネスの上で自律ループを回す設計

ループエンジニアリングは、人間が手作業で行っていた「確認・合否判定・やり直し指示」を、AI と自動検証の仕組みに委ねるアプローチです。

安全なハーネス（隔離と可逆性の保証）を大前提として、外部記憶・自走権限・客観的判定ロジック という 3 つの足場を整え、AI 自身に検証と自己進化のサイクルを実行させます。課題や運用コストも伴うアプローチですが、人間による手動介入のボトルネックを解消し、プロンプトの工夫から「自走する仕組みの設計」へと移行するための実践的なアプローチとして紹介しました。

参考リンク・情報ソース

ループ工学・エージェント設計

学術論文（外部記憶・コンテキスト特性）

なぜ境界防御は敗北したのか？：痛みのピラミッドから読み解く MITRE ATT&CK 誕生の歴史と防御のパラダイムシフト

Sun, 16 Aug 2026 11:46:00 +0000

個人用メモ・備忘録

はじめに

今日のサイバーセキュリティ業界において、脅威分析、EDR の検知ルール作成、レッドチーム演習の共通基盤として使われているのが MITRE ATT&CK（マイター・アタック） です。

しかし、なぜ世界中のセキュリティ機関や企業がこの巨大なマトリクスを参照するようになったのでしょうか？

その背景には、かつてセキュリティ業界が信じていた 「境界防御とブラックリストの完全な敗北」 と、そこから生まれた 「発想のコペルニクス的転回」 という歴史的なパラダイムシフトがありました。

本記事では、MITRE ATT&CK が誕生した歴史的背景、David Bianco 氏の「痛みのピラミッド」、TTPs（戦術・手法・手順）の構造、そして防御技術の体系化（D3FEND）に至る進化の軌跡を整理します。

境界防御の限界と「痛みのピラミッド」

2000 年代から 2010 年代初頭にかけて、企業のサイバーセキュリティは 「境界防御（Perimeter Defense）」 と 「シグネチャ・ブラックリスト」 が中心でした。

社内ネットワークの出入り口にファイアウォールや IDS/IPS を設置し、侵入を水際でブロックする。
既知のマルウェアのハッシュ値（MD5, SHA-256）や悪意ある IP アドレス・ドメイン名（IOC: Indicators of Compromise）を登録し、合致した通信を遮断する。

[ インターネット ] ──(攻撃)──> [ ファイアウォール (境界) ] ──(遮断)──> [ 社内ネットワーク ]
 │
 【すり抜けた場合、内部は無防備】

なぜブラックリスト方式は破綻したのか？

攻撃者（APT 攻撃グループ等）の技術が進化するにつれ、このアプローチは構造的な限界に直面しました。

攻撃者はマルウェアのコードを 1 バイト書き換えるだけでハッシュ値を無効化でき、クラウドや動的 DNS を使って 1 秒で新しい IP アドレスやドメインを取得できたためです。防御側がどれほど多額の投資をしてブラックリストを更新しても、攻撃者はノーコストですり抜けていきました。

痛みのピラミッド（The Pyramid of Pain）

この絶望的な非対称性を 2013 年に見事に言語化したのが、セキュリティ研究者の David J. Bianco 氏 による 『Pyramid of Pain（痛みのピラミッド）』 です。

 ▲
 / \
 / \ TTPs（攻撃者の行動パターン・戦術） 【極めて痛い (Tough!)】
 / TTP \
 /-------\
 / Tools \ Tools（攻撃ツール・Mimikatz, Cobalt Strike 等）
 /-----------\
 / Network \ Network / Host Artifacts（C2通信の痕跡、URI パターン）
 /---------------\
 / Domain Names \ Domain Names（悪意あるドメイン名）
 /-------------------\
 / IP Addresses \ IP Addresses（攻撃元 IP アドレス）
 /-----------------------\
 / Hash Values \ Hash Values（SHA-256, MD5 ハッシュ） 【全く痛くない (Trivial)】
 /---------------------------\

ピラミッドの下層にある要素ほど、防御側がブロックしても攻撃者は簡単に変更できます（Trivial / Easy）。逆に、ピラミッドの頂点にある 「TTPs（Tactics, Techniques, and Procedures：攻撃者の行動パターン）」 を封じられると、攻撃者は攻撃手順やツールの再設計、工作員の再訓練を強いられ、最も大きな打撃（Tough!） を受けます。

ここから、「侵入を 100% 防ぐことは不可能である（Assume Breach: 侵入前提）」 という新たな共通認識が生まれました。

MITRE ATT&CK の誕生：道具ではなく「行動」を追え

2013 年、米国の非営利研究機関 MITRE（マイター） は、自組織の研究プロジェクト（FMX: Fort Meade Experiment）の中で、実世界の標的型攻撃データを分析していました。

研究者たちは、従来の IOC（IP やハッシュ）追跡から脱却し、次のような根本的な問いを立てました。

こうして、実世界の攻撃者が侵入後に実行するすべての手口を網羅・体系化したカタログ、MITRE ATT&CK（Adversarial Tactics, Techniques, and Common Knowledge） が誕生しました。

【従来の着眼点】
「どんなマルウェアファイル（道具）が使われたか？」（ハッシュ値、ファイル名）

【MITRE ATT&CK の着眼点】
「攻撃者は何を目的として、OS のどの機能をどう悪用したか（行動）？」（プロセスインジェクション、LSASS メモリダンプ等）

ATT&CK の基本構造とマトリクス設計

ATT&CK は、攻撃者の行動を 「Tactics（戦術：目的）」 と 「Techniques（手法：手段）」 の 2 軸マトリクスで表現します。

flowchart TD
 Tactic["Tactics（戦術：Why）<br>例: Credential Access（認証情報の窃取）"]
 --> Technique["Techniques（手法：How）<br>例: OS Credential Dumping (T1003)"]
 --> SubTech["Sub-techniques（詳細手法）<br>例: LSASS Memory (T1003.001)"]
 --> Procedure["Procedures（実行例・手順）<br>例: APT29 が Mimikatz を用いて LSASS プロセスから平文パスワードをダンプ"]

TTPs の 4 階層モデル

階層	意味	問い	具体例
Tactics（戦術）	攻撃者の目的	何を達成したいのか？	初期侵入（Initial Access）、権限昇格（Privilege Escalation）、横展開（Lateral Movement）
Techniques（手法）	目的達成の手段	どのように実行するのか？	OS Credential Dumping（T1003）、Process Injection（T1055）
Sub-techniques	手法のより詳細な分類	具体的にどの機能を使うのか？	LSASS Memory（T1003.001）、NTDS（T1003.003）
Procedures（手順・実例）	実際の攻撃グループの記録	誰が実際にどう悪用したのか？	APT28 が特定のコマンドライン引数で `rundll32.exe` を実行

対象ドメインの分類（Enterprise・Mobile・ICS）

ATT&CK は、IT インフラの多様化に合わせて 3 つのドメインに拡張されています。

ドメイン	対象環境	主な特徴
Enterprise	Windows, Linux, macOS, AWS, Azure, GCP, Active Directory, Office 365	企業システム全般。クラウド環境や SaaS に対するアイデンティティ攻撃も網羅
Mobile	Android, iOS	モバイル端末特有のサンドボックス回避、不正プロファイル、通信傍受
ICS	SCADA, PLC, 産業制御システム, 発電所・工場	物理機器の制御停止、セーフティシステムの無効化などプラント特有の破壊手口

防御側のマッピング情報と活用モデル

ATT&CK が真に画期的だったのは、「攻撃のカタログ」でありながら、すべてのマス目に「防御情報」が 1 対 1 で紐づいている点 です。

Technique: OS Credential Dumping (T1003.001 - LSASS Memory)
├── Data Sources: Process Access (Sysmon Event ID 10), Command Execution
├── Detection: lsass.exe に対する PROCESS_VM_READ 権限のオープンを監視
└── Mitigations: LSA Protection (RunAsPPL) の有効化、Credential Guard の導入

Data Sources（データソース）: その手口を検知するために、どのログ（プロセス生成、レジストリ変更、ネットワーク接続等）を収集すべきか。
Detection（検知ロジック）: SIEM や EDR でどのような相関ルールやシグネチャを組むべきか。
Mitigations（予防策）: 設定変更やアーキテクチャ見直しによって、その手法を根本的に無効化できるか。

防御側の逆転：死角の可視化から D3FEND へ

ATT&CK という「共通言語（共通の物差し）」を手に入れたことで、防御側の運用は劇的に進化しました。

1. カバレッジの可視化とスコアリング（DeTT&CT）

ATT&CK Navigator: ブラウザ上でマトリクスを表示し、自社が検知できるマス（緑）と検知できないマス（赤）をヒートマップで可視化。
DeTT&CT (github.com/rabobank-cdc/DeTT&CT): 収集ログの品質と検知ルールの有効性を評価し、「自社の防御体制における死角（ブラインドスポット）」 を客観的データとしてスコアリング。

2. 防御技術のオントロジー「MITRE D3FEND」

攻撃者の手口（ATT&CK）が体系化されたのを受け、MITRE は 2021 年、米国 NSA の支援のもと MITRE D3FEND (d3fend.mitre.org) を公開しました。

ATT&CK が「攻撃側の手口」 であるのに対し、D3FEND は「防御側の対抗技術」（ファイル整合性監視、プロセスメモリ暗号化、セッション無効化等）を精密に定義・マッピングしたオントロジーです。
これにより、「どの攻撃手法（ATT&CK）に対して、どの防御技術（D3FEND）を配置すれば最も効率的に防御網を築けるか」を論理的に設計できるようになりました。

まとめ

境界防御の破綻: ハッシュ値や IP を追う IOC 追跡は、攻撃者にとって痛くない（痛みのピラミッド）。
行動（TTPs）への着眼: 攻撃者が簡単に変更できない「侵入後の行動パターン」を捉えることで、防御側の優位性を確立。
共通言語としての ATT&CK: 「Tactics（目的）× Techniques（手口）」のマトリクスにより、セキュリティの死角を定量的に可視化。
D3FEND への発展: 攻撃の周期表から防御技術のオントロジーへと進化し、論理的な防御アーキテクチャ設計が可能に。

参考リンク・情報ソース

なぜ「ローカル環境構築」は破綻したのか？：秘伝のタレの終焉と Dev Containers による開発環境のコード化

Sun, 16 Aug 2026 11:45:00 +0000

個人用メモ・備忘録

はじめに

ソフトウェアエンジニアなら誰もが一度は経験したことのある「儀式」があります。

新しい PC を手に入れた日、あるいは新しいプロジェクトに参画した初日、README に書かれた長大なセットアップ手順と格闘し、ターミナルでエラーが出るたびに検索し、気づけば休日や参画初日が丸ごと潰れていた──という苦い記憶です。

なぜ、言語やツールのバージョン管理ツールが充実した現代においても、ローカルマシンの環境構築はこれほどまでに壊れやすく、再現性が失われてしまうのでしょうか？

本記事では、「ローカル環境構築の暗黒時代」から「Dev Containers による開発環境のコード化」に至るパラダイムシフトの歴史、そして AI エージェント時代においてコンテナが 「不可欠な安全装置（ハーネス）」 となった必然性を整理します。

秘伝のタレと環境構築の暗黒時代

かつて開発環境の構築といえば、ホスト OS（macOS や Linux、Windows）の上に各種言語ランタイムを直接インストールするのが当たり前でした。

[ ホスト OS ]
├── Node.js (nvm で管理)
├── Python (pyenv で管理)
├── Ruby (rbenv で管理)
├── Go (asdf で管理)
├── PostgreSQL, Redis (Homebrew でローカル起動)
└── ~/.zshrc (数百行におよぶ秘伝のタレ設定)

しかし、このアプローチはプロジェクトが増えるにつれて構造的な破綻を迎えました。

1. バージョンマネージャーの乱立とシェルの遅延

プロジェクトごとに異なる言語バージョンを切り替えるため、nvm、pyenv、rbenv、asdf、mise などのバージョンマネージャーが導入されました。

しかし、これらのツールはシェルの起動時に環境変数をフックし、shims ディレクトリを経由してコマンドを実行するため、ターミナルを開くたびに 1〜2 秒の起動遅延が発生する ようになりました。

2. 「私のマシンでは動く（It works on my machine）」の呪い

OS のマイナーアップデート、Homebrew で入れた共有ライブラリ（OpenSSL や libxml2）のバージョン差異、グローバルにインストールされたツールの微妙な違いにより、「A さんの Mac では動くが、B さんの Mac ではビルドがコケる」という不毛なデバッグ時間がチーム内で頻発しました。

3. PC 移行時の恐怖

一度構築した環境は、手作業で継ぎ足された設定やキャッシュの塊（いわゆる「秘伝のタレ」）と化します。そのため、PC の故障や買い替えのたびに同じ環境を再現できず、環境構築手順書（README）は書かれた翌週には陳腐化していきました。

パラダイムシフト：「環境は育てるものではなく、使い捨てるもの」

インフラの世界では、かつてサーバーを手作業で丹精込めて管理する 「ペット（Pet）」 から、設定ファイルからいつでも同一のものを自動生成・破棄できる 「家畜（Cattle / Disposable Infrastructure）」 への転換が起きました。

これと全く同じ思想的転換が、開発環境にももたらされました。それが、オープン標準規格として標準化された 「Dev Containers（Development Containers）」 です。

【従来の思想（ペット）】
ホスト OS を何年もかけてカスタマイズし、壊れないように慎重に保守する。

【Dev Containers の思想（使い捨て）】
開発環境は Dockerfile と devcontainer.json の定義から数分で生成し、
用が済んだり汚れたらいつでも気軽に破棄して再生成する。

なぜ Dev Containers は画期的なのか？

単に「Docker コンテナの中でコードを書く」だけであれば、以前から可能でした。しかし、従来の Docker 開発には大きな不便がありました。

コンテナ内で Vim や Nano などの CUI エディタを使うか、ホスト側エディタとコンテナ内の言語サーバー（LSP）を手動で繋ぐ必要があり、設定が極めて難解だった。
ポートフォワーディング、SSH 鍵や Git 認証の引き継ぎを手動で設定しなければならなかった。

VS Code の Dev Containers 拡張 は、「エディタの UI だけをホストで動かし、拡張機能・言語サーバー・デバッガ・ターミナルなどの開発エンジンを丸ごとコンテナ内で動かす」 というクライアント/サーバー分離アーキテクチャを採用することで、ホスト上で直接開発しているのと全く変わらない快適性を実現しました。

[ ホスト OS ]
 VS Code UI（画面描画、キー入力）
 │
 │ (IPC / VS Code Server 接続)
 ▼
[ Docker コンテナ (DevContainer) ]
 ├── 言語ランタイム (Go, Python, Node 等)
 ├── 言語サーバー (gopls, pyright 等)
 ├── デバッガ・CLI ツール
 └── ソースコード・作業ツリー

開発環境をコンテナ化して得られた 3 つの決定打

1. ホストマシンの完全な環境保全

ホスト OS にインストールするソフトウェアは 「Docker Desktop（または OrbStack 等）」 と 「VS Code」 の 2 つだけで完結します。

Go や Ruby、特定のバージョンの Node.js などをホストに一切インストールしないため、ホストの .zshrc は数行で済み、ターミナルは一瞬で起動します。プロジェクトが終わればコンテナとイメージを削除するだけで、ホストに 1 バイトのゴミも残りません。

2. 環境のコード化（Infrastructure as Code）と完全な再現性

環境の定義はすべてリポジトリ内の .devcontainer/devcontainer.json と Dockerfile に記録されます。

{
 "name": "My Project Environment",
 "build": { "dockerfile": "Dockerfile" },
 "features": {
 "ghcr.io/devcontainers/features/node:1": { "version": "22" }
 },
 "customizations": {
 "vscode": {
 "extensions": ["golang.go", "esbenp.prettier-vscode"]
 }
 }
}

チームメンバーはリポジトリをクローンして「Reopen in Container」ボタンを 1 クリックするだけで、全員が寸分違わぬ同一のツールチェーン、LSP、VS Code 拡張機能が揃った状態で即座に開発を始められます。

3. AI エージェントを野に放つ「物理ハーネス（安全な檻）」

近年の自律型 AI コーディングエージェント（Antigravity、Claude Code 等）の台頭により、コンテナ開発の重要性はさらに跳ね上がりました。

AI エージェントに「自律的にコマンドを実行してテスト・ビルド・修正を繰り返すループ」を任せる際、ホスト OS 上で直接シェル権限を渡すのは極めて危険です。AI が誤って重要ファイルを一括削除したり、意図しないシステム設定を書き換えるリスクがあるためです。

【ホストで直接動かすリスク】
AI エージェント ──(rm -rf や危険コマンド)──> [ ホスト OS の重要データが破壊される ]

【DevContainer 内で動かす安全性】
AI エージェント ──(自律実行ループ)──> [ コンテナ内部のみで完結 ]
 （最悪壊れてもコンテナを再構築するだけ）

コンテナという OS カーネルレベルの物理隔離（ハーネス） があるからこそ、人間は恐怖を感じることなく AI エージェントにフル権限を委ね、自走ループを回すことが可能になります。

運用上の留意点とトレードオフ

万能に見える Dev Containers ですが、実務で導入する際には以下のトレードオフを理解しておく必要があります。

ディスク容量の消費:
- 複数のプロジェクトで異なるコンテナイメージを保持すると、数十 GB のディスクを消費します。定期的に docker system prune を実行する運用が必要です。
初期ビルドのオーバーヘッド:
- 初回起動時やイメージ再構築時にコンテナビルドの待ち時間（数分）が発生します。
ファイルシステムの I/O 性能（特に macOS / Windows）:
- ホストとコンテナ間のファイルマウント（bind mount）において、I/O 負荷の高い処理（大量の node_modules の読み書き等）でパフォーマンスが低下する場合があります（Named Volume の活用や VirtioFS の利用で大幅に改善可能）。

まとめ

秘伝のタレの終焉: ホスト OS に言語バージョンマネージャーを積み重ねるローカル環境構築は、再現性と保守性の面で限界を迎えた。
使い捨ての思想: 開発環境をコード化し、いつでも同一の環境を生成・破棄できる Dev Containers により、「私のマシンでは動く」問題を根本解決。
AI 時代の必須基盤: 自律 AI エージェントに安全な自走ループを委ねるための「物理ハーネス」として、コンテナ開発は不可欠な土台となった。

Sesame blog

「コードを書くだけ」の時代は終わった：AI コーディングエージェントの非開発応用と Antigravity Python SDK の本質

はじめに

なぜ「コーディング」から始まったのか？──閉じたループの必然性

Antigravity Python SDK が存在する真の理由

「人間対面（Chat）」から「システム組み込み（Headless Runtime）」への飛躍

開発用途を超えた 5 つの実務ユースケース

ユースケース詳細

1. DataOps：アドホック分析とビジュアルレポートの完全自動化

2. SRE / インフラ運用：障害の自律トリアージ

Python SDK による実装例：SRE 障害調査エージェント

エンタープライズ導入における安全設計（Safety by Default）

運用で AI エージェントを活用する 3 つのアプローチと使い分け

各アプローチの背景と実例

1. コーディングエージェント流用型：なぜ「非公式」な使い方が最も柔軟なのか？

2. プロコード自作型：Antigravity Python SDK や LangGraph による統制

3. 専用エージェント型：OpenClaw や CNCF プロジェクトの台頭

実務での判断基準（Decision Flow）

まとめ

参考リンク・情報ソース

Antigravity エコシステムの全体像：VS Code 拡張機能・Antigravity 2.0・agy CLI・Python SDK の役割と使い分け

はじめに

開発者 AI が直面していた「形態の分断」と進化の必然性

共通基盤アーキテクチャ（Shared Agent Core）

共通コアが提供する 4 大要素

提供形態（Surfaces）の比較と特徴

1. VS Code 拡張機能（エディタ一体型）

主な機能

2. Antigravity 2.0（デスクトップ司令塔）

主な機能

3. Antigravity CLI (agy)（ターミナル特化）

主な機能

4. Antigravity Python SDK（プログラム組み込み）

主な特徴と用途

機能差の縮小によって浮き彫りになった「GUI と CLI の真の役割分担」

なぜバイブコーディングや自律実行では CLI が最適解なのか？

1. 直接実行力と低レイテンシ（High Agency & Native Habitat）

2. 「コマンド検索」によるコンテキスト純度（S/N 比）の極大化

3. 「作って終わり」にしない自己検証・修復ループ（Execution-Feedback Loop）

4. マルチプレキシング（5〜10 台以上の並列同時自走）

提供形態ごとの最終的な役割分担

まとめ

参考リンク・情報ソース

Python 開発を効率化するモダンターミナル環境設計：Ghostty・fish・peco・ghq・tmux・Jujutsu・VS Code・Herdr・Hunk 連携

はじめに

ツールスタックとそれぞれの役割（レイヤー構造）

各ツールの役割と導入メリット

Ghostty：高速・低遅延な GPU ターミナル基盤

ghq によるリポジトリ管理の統一

fish ＋ peco による 1 キープロジェクト移動

関数の実装 (~/.config/fish/functions/fish_user_key_bindings.fish)

tmux / herdr によるセッション永続化と AI 状態管理

tmux：プロジェクト単位の作業部屋自動作成

herdr：AI エージェント協働時代のマルチプレクサ

Python 仮想環境（uv / venv）の自動アクティベーション

Jujutsu（jj）：Git 互換の次世代バージョン管理

なぜ Python 開発 / AI 協働で jj が強力なのか？

差分レビューと部分コミットの高速化「hunk」

VS Code 連携：CLI からのワンショット起動

推奨設定ファイル一覧

~/.config/fish/config.fish

~/.tmux.conf（抜粋）

まとめ

参考リンク・情報ソース

Model Context Protocol（MCP）の仕様と設計：AI と外部ツールを繋ぐオープン標準

はじめに

MCP の誕生とオープン標準化（AAIF 移管）

アーキテクチャと通信モデル

3 つのコンポーネント

通信トランスポート（Stdio と SSE）

中核機能（Primitives）の構成

1. Tools（ツール実行）

2. Resources（コンテキストデータ供給）

3. Prompts（対話テンプレート）

Rules・Skills・Agent Plugins との役割分担

Agent Skills と比較した MCP の 5 つの固有メリット

1. JSON Schema による厳格な型安全性と引数のバリデーション

2. ターミナル権限を開放しない「最小権限のセキュリティ」

3. リモート・クラウド接続性と環境非依存のポータビリティ

4. 常駐プロセスによる「コネクションプール・セッションの維持」

3. Antigravity CLI (`agy`)（ターミナル特化）

関数の実装 (`~/.config/fish/functions/fish_user_key_bindings.fish`)

なぜ Python 開発 / AI 協働で `jj` が強力なのか？

`~/.config/fish/config.fish`

`~/.tmux.conf`（抜粋）

設定ファイルの構造（`mcp_config.json` / `mcp.json`）

`SKILL.md`（必須）

`references/`（任意：参照ドキュメント）

`scripts/`（任意：実行コード）

`assets/`（任意：静的アセット）

`evals/`（任意：評価テスト）

`SKILL.md` の仕様と記述例

2. `SKILL.md` の実践例

2. GitHub Copilot (`.github/copilot-instructions.md`)

3. Cursor (`.cursorrules` / `.cursor/rules/*.mdc`)

`plugin.json` の仕様

1. プラグイン定義 (`plugin.json`)

2. リリース手順書 (`skills/prepare-release/SKILL.md`)

3. 実行スクリプト (`skills/prepare-release/scripts/check-diff.sh`)

4. 外部ツール接続 (`mcp.json`)