はじめに

以前、「[Claude Code × Codex × Obsidian Vault ― AI 二刀流で作る「何でも相談」環境の全設定公開]」という記事で、Claude Code と Codex を両方使う相談・開発環境を紹介しました。あれから運用を重ねた結果、今は GitHub Copilot（VS Code）だけに一本化しています。この記事では、その現在の構成を改めて全部公開します。

対象読者は前回記事を読んだ方はもちろん、GitHub Copilot Chat でエージェント的な使い方（instructions・skills・カスタムエージェント・hooks）をしたい人全般です。Obsidian は未経験でも読めるようにします。

なぜ一本化したのか

前回記事を読み返すと、Codex との二者運用は正直かなり手間がかかっていました。Windows の Codex sandbox が Google Drive の仮想ドライブ上で初期化に失敗する問題、agmsg 経由でエージェント間メッセージを送るための常駐プロセス、.codex/hooks と .claude/settings.json を両方メンテナンスする二重管理……。「レビュー役を分ける」というアイデア自体は良かったのですが、それを実現するための配線が複雑になりすぎていました。

GitHub Copilot は VS Code に統合されていて、instructions・カスタムエージェント・スキル・hooks をひとつのツールの中で完結させられます。エージェント間通信のための別プロセスも要りません。「実行役とレビュー役を分ける」という設計思想はそのまま引き継ぎつつ、配線だけを単純化した、というのが今回の変更の要点です。

変わったこと・変わらなかったこと

プロジェクトの土台にしていた3原則は、今も基本的に生きています。

成果物は全部 Obsidian Vault に入れる（変わらず）
置き場ルールは常時ロードされる指示ファイルに書いて、エージェント自身に守らせる → 正本が AGENTS.md から .github/copilot-instructions.md に変わった
Mac と Windows をポータブルに行き来できる設計（絶対パス禁止・UTF-8・LF）→ 変わらず。Google Drive 同期の実フォルダをローカルに置く運用も継続

3番目に書いた「Windows sandbox と仮想ドライブの相性問題」は、そもそも GitHub Copilot にはサンドボックス起動の概念がないため、今回の移行で自然に解消しました。問題を解決したというより、問題を抱えていた仕組みごと手放した、というのが実態に近いです。

プロジェクト全体像とフォルダ構成

現在のフォルダ構成はこうなっています。

何でも相談-pj/
├── README.md                      # 初回セットアップ手順
├── .mcp.json                      # Agent Host が可搬設定として直接読むMCP設定
├── .vscode/
│   └── mcp.json                   # VS Code Chat UI 用のMCP設定
├── .github/
│   ├── copilot-instructions.md    # 常時ロードされる共通指示（正本）
│   ├── instructions/              # 作業種別ごとの applyTo 指示（ポインタ）
│   ├── agents/                    # カスタムサブエージェント
│   ├── skills/                    # ドメイン知識スキル（SKILL.md）
│   └── hooks/                     # ツール呼び出し前後のフック定義
├── guidelines/                    # ルール本文の正本置き場
├── scripts/                       # 補助スクリプト
├── hooks/                         # hook の実処理スクリプト（.cjs）
├── legacy-claude-codex/           # 旧 Claude Code / Codex 設定の退避先（非アクティブ）
└── obsidian-vault/                # Obsidian Vault ルート
    ├── daily/                     # デイリーノート
    ├── coding/
    │   └── reviews/               # レビュー依頼ノート
    ├── research/                  # 技術調査・学習メモ
    ├── docs/                      # ドキュメント下書き・成果物
    ├── references/                # 参考資料
    └── archive/                   # 終了した相談のアーカイブ

Vault の中身（daily coding research docs references archive）は前回記事とほぼ同じです。変わったのはプロジェクトルート側で、AGENTS.md や .claude/ .codex/ .agents/ がまるごと .github/ 配下の仕組みに置き換わりました。旧設定は消さず legacy-claude-codex/ に退避してあります。過去の設定判断を後から追えるように残しているだけで、今は読み込まれません。

copilot-instructions.md ― 常時ロードされる指示の正本

.github/copilot-instructions.md が、以前の AGENTS.md に相当する常時ロードファイルです。ここには「会話は日本語で行う」「作業前に既存ファイルを確認する」といった基本ルールに加えて、フォルダごとの責務を書いています。

## フォルダ構成と責務

| 場所 | 役割 |
| --- | --- |
| `.github/copilot-instructions.md` | このファイル。プロジェクト共通指示の正本 |
| `.github/instructions/` | 作業種別ごとの on-demand / applyTo 指示 |
| `.github/agents/` | カスタムサブエージェント定義 |
| `.github/skills/` | ドメイン知識スキル |
| `guidelines/` | 思想、文体、ルール本文の正本置き場 |
| `obsidian-vault/` | Obsidian Vault ルート |

大事なのは、ここには「思想」しか書かず、細かいルール本文は書かないことです。理由は次のセクションで説明します。

instructions/ ― 正本とポインタを分けた二階建て構造

前回の AGENTS.md は、運用を重ねるうちにどんどん長くなっていました。スキル利用ポリシー、文字コードルール、Git/gh運用ルール……全部を1ファイルに詰め込んでいたので、常時ロードされるコンテキストが肥大化していたのです。

今の構成では、ルール本文を guidelines/ に切り出し、.github/instructions/ にはそこへの「ポインタ」だけを置いています。ポインタ側には applyTo という frontmatter があり、該当パターンのファイルを編集するときだけ自動でアタッチされます。

---
description: "Obsidianノート・ドキュメント・記事・図表の作成や編集、Webからの抽出をするときに使う。スキル一覧と適用場面、humanizerの適用範囲。"
applyTo: "obsidian-vault/**"
---

# スキル利用ポリシー（ポインタ）

このプロジェクトには作業の種類ごとに使うスキルがある。Obsidian ノート・ドキュメント・
記事・図表の作成や編集、Web からの抽出などをするときは、`guidelines/skill-policy.md` の
スキル一覧と適用場面、humanizer の適用範囲を読んで該当スキルを使う。

スキル一覧という本文は `guidelines/skill-policy.md` に一本化し、ここはポインタで内容を
二重管理しない。

今用意している5つの instructions はこれです。

ファイル	`applyTo`	内容
`encoding.instructions.md`	スクリプト・設定全般	文字コード・改行・先頭行のルール
`git-gh.instructions.md`	`obsidian-vault/coding/**`	Git/gh コマンドの禁止・許可制・読み取り専用の分類
`obsidian-markdown.instructions.md`	`obsidian-vault/*/.md`	frontmatter・wikilinks・embeds・callouts のルール
`review-flow.instructions.md`	`obsidian-vault/coding/reviews/**`	レビュー依頼ノートの役割分担と5セクション構成
`skill-policy.instructions.md`	`obsidian-vault/**`	スキル一覧と適用場面

「本文は guidelines/ に1つだけ、.github/instructions/ は薄いポインタ」という分業のおかげで、ルールを変えたいときは guidelines/ の1ファイルを直すだけで済みます。以前は AGENTS.md の該当箇所を探して直す作業がそれなりに手間でした。

skills/ ― ドメイン知識を SKILL.md にパッケージ化する

スキルの仕組み自体は前回とほぼ同じで、SKILL.md の description を見てエージェントが自動的に「これは今関連しそうだ」と判断し、必要なときだけ本文を読みに行きます。現在使っているのは8つです。

スキル	適用場面
`obsidian-markdown`	Vault 内 `.md` の作成・編集
`humanizer`	文章生成時のAI臭さ除去
`note-article-writing`	note.com 向け記事の執筆・公開前チェック
`obsidian-bases`	`.base` ファイルの作成・編集
`json-canvas`	`.canvas` ファイルの作成・編集
`obsidian-cli`	Obsidian 起動中の CLI 操作
`defuddle`	Web ページからの Markdown 抽出
`review-note`	レビュー依頼ノートの作成・完了記録

前回からの実質的な追加は review-note です。これは次に説明するカスタムエージェントとセットで、レビューフローを簡素化するために新設しました。

agents/ ― 役割を分離したカスタムサブエージェント

Codex という別ツールに任せていた「レビュー役」は、今は GitHub Copilot のカスタムエージェント機能に置き換えました。.github/agents/ に2つ定義しています。

---
description: "実装・コード変更・設定変更のレビューを行うとき使う。..."
tools: [read, search]
model: "Claude Sonnet 5"
reasoning-effort: "xhigh"
user-invocable: true
disable-model-invocation: false
---
あなたはこのプロジェクト専用のレビュー担当サブエージェントです。

## 制約
- DO NOT ファイルを編集しない。読み取り専用として振る舞う
- DO NOT 変更の承認・却下を最終判断しない。判断は必ずユーザーに委ねる

reviewer は tools: [read, search] で編集系ツールを最初から持たせていません。「レビュー役は書き込めない」という制約をプロンプトの努力目標ではなく設定レベルで強制できるのは、地味に安心感があります。

もうひとつが project-auditor で、こちらは指示・スキル・エージェント・hooks・MCP設定の間に矛盾がないかを棚卸しする専用エージェントです。

---
description: "このプロジェクトの設定の棚卸し・整合性チェックを行うとき使う。読み取り専用。"
tools: [read, search]
user-invocable: true
disable-model-invocation: true
---

disable-model-invocation: true にしているのがポイントです。これは「メインエージェントが会話の流れで勝手に呼び出さない」設定で、明示的に指名したときだけ動きます。設定の棚卸しは頻繁にやる作業ではないので、意図せず毎回走られても困る、という判断でこうしました。

hooks/ ― 機械的に守らせたいルールはコードで縛る

指示ファイルに「機密ファイルは編集しない」と書いても、それだけでは100%守られるとは限りません。確実に止めたいものは hook にしています。

.github/hooks/ にフックの定義があり、実処理は hooks/*.cjs に書いています。

{
  "hooks": {
    "PreToolUse": [
      {
        "type": "command",
        "command": "node hooks/prevent-secret-edit.cjs",
        "timeout": 15
      }
    ]
  }
}

prevent-secret-edit.cjs は Edit/Write の直前に走り、.env や credentials、鍵ファイル（.pem .key など）への書き込みをブロックします。最初はファイルパスに token などの部分文字列が含まれているだけで止める単純な実装にしていたのですが、それだと prevent-secret-edit.cjs 自身や token を含むノート名まで誤爆してしまいました。今は「拡張子 × ファイル名の単語境界」で判定するように直してあります。地味な話ですが、hook はガードが厳しすぎると本来の作業を止めてしまうので、このくらいの調整は必要でした。

もうひとつの check-obsidian-frontmatter.cjs は Write の直後に走り、obsidian-vault/ 配下の .md に frontmatter が無ければ警告を出します。強制ブロックではなく警告に留めているのは、今回の記事のような Qiita 下書きは意図的に frontmatter を付けない運用にしているからです。全部を機械的に縛ると、こういう例外が扱いにくくなります。

MCP設定 ― 必要なサーバだけを絞る

MCPサーバの定義は .vscode/mcp.json（VS Code Chat UI 用、servers キー）と、ルートの .mcp.json（Agent Host が可搬設定として直接読む用、mcpServers キー）の2箇所にあります。キー名が違うだけで中身は揃えています。

{
  "servers": {
    "aws-documentation": {
      "type": "stdio",
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR",
        "AWS_DOCUMENTATION_PARTITION": "aws"
      }
    },
    "playwright": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest"]
    }
  }
}

前回使っていた NotebookLM MCP は今は定義していません。Google ログインの維持コストの割に使用頻度が低かったので、素直に外しました。playwright は定義だけ残していて既定オフ扱いです。ブラウザ操作が必要なときだけ VS Code の MCP: List Servers から一時的に有効化し、使い終わったら無効に戻す運用にしています。MCP は増やすほどコンテキストを消費するので、「常時使うものだけ有効化」という方針は前回から変えていません。

レビューフローの簡素化

前回のレビューフローは、Claude の Stop フックが agmsg を使って Codex にメッセージを送り、Codex 側の Stop フックが inbox を確認しに来る、という非同期の仕組みでした。動けば便利でしたが、常駐プロセスの管理やメッセージのタイムアウトなど、考えることが多い構成でもありました。

今は同じツールの中でサブエージェントを呼び出すだけなので、フローが1本の流れに収まっています。

メインエージェントが実装・変更を行う
review-note スキルの手順で obsidian-vault/coding/reviews/YYYY-MM-DD-<トピック>.md にレビュー依頼ノートを作る（レビュー対象／確認してほしい観点／レビュー結果／対応メモ／完了記録の5セクション）
メインエージェントが reviewer サブエージェントを呼び出す
返ってきた指摘を「レビュー結果」セクションに転記し、必要な修正を行う
修正内容を「対応メモ」に、完了後の状態を「完了記録」に書く

外部プロセスへの送信も、inbox のポーリングもありません。Obsidian Vault が「実行役とレビュー役の共有データベース」として機能する、という考え方自体は前回から変わっていませんが、配線はだいぶ軽くなりました。

memory ツール ― エージェントが自分でメモを残す仕組み

前回の構成には無かった要素として、GitHub Copilot のエージェントには /memories/ というメモリ機能があります。3層に分かれていて、/memories/（環境全体で永続）、/memories/session/（今回の会話限定）、/memories/repo/（このワークスペース固有）という使い分けです。

このプロジェクトでは /memories/repo/structure.md に、今回の GitHub Copilot 移行の要点（何が変わったか、旧設定の場所、注意点）を書き残しています。次にこのプロジェクトを開いたとき、毎回イチから構成を説明しなくても、エージェント自身が過去の作業メモを参照できる。ファイルをコミットするわけではないので guidelines/ とは役割が違いますが、「エージェントが自分の作業履歴を持てる」というのは地味に大きい変化だと感じています。

旧構成（Claude Code / Codex）の扱い

legacy-claude-codex/ に AGENTS.md CLAUDE.md .claude/ .codex/ .agents/ をまるごと退避してあります。削除ではなく退避にしたのは、単純に「あとで見返したくなる可能性がある」からです。実際、今回の記事を書く過程でも「あのときの settings.json はどう書いていたか」を確認するのに何度か覗きました。使わなくなった設定でも、当分は残しておいて損はありません。

まとめ：今日からマネできる最小セット

GitHub Copilot でこの手の環境を組みたい場合の最小手順です。

VS Code + GitHub Copilot を入れ、プロジェクトフォルダの中に obsidian-vault/ を作る
.github/copilot-instructions.md に、常時守ってほしい思想レベルのルール（会話は日本語で、成果物は Vault 配下に、フォルダごとの責務表）だけを書く
細かい作業別ルールは guidelines/*.md に本文を書き、.github/instructions/*.instructions.md に applyTo 付きのポインタを置く。本文とポインタを分けておくと、後から直すときに1箇所で済む
繰り返し使う知識は .github/skills/<スキル名>/SKILL.md にまとめる
「実行役」と「レビュー役」のように役割が違うタスクは .github/agents/*.agent.md でカスタムサブエージェントに分ける。読み取り専用にしたいエージェントは tools を絞り、自動起動させたくないなら disable-model-invocation: true にする
絶対に守らせたいルール（機密ファイル保護など）は .github/hooks/*.json と実処理スクリプトの hook にする。指示文だけに頼らない
MCPサーバは常時使うものだけ .vscode/mcp.json に定義し、使用頻度が低いものは思い切って外す

前回の記事のときは「Claude と Codex、2つのAIエージェントを併用する」という新しさ自体が主役でした。今回はその逆で、「1つのツールにどこまで役割分担と自動化を持ち込めるか」が主題になっています。ツールを減らしたのに前回よりできることが増えている、というのが今の実感です。

参考リンク