目次
- 目次
- 1. 効率的な開発の土台：ghq でリポジトリを整理し、Organizationレベルで管理を行う
- 2. AIエージェント設定の役割分担
- 3. 実践：AIを「業務ナビゲーター」に変える
- 4. 動作の速さを重視：GitHub Copilot CLIの常用
- まとめ：コンテキストを整え、責任を持って「使いこなす」
こんにちは。ACS事業部の青木です。 先日、同じ事業部の越川さんが以下のようなブログを出されていました。
こちらで話されていた「もう一人のスピーカー」が私です。 そこで、せっかくなのでお話しさせていただ内容+αをブログにしてみたいと思います。
1. 効率的な開発の土台：ghq でリポジトリを整理し、Organizationレベルで管理を行う
私の開発環境では、すべてのリポジトリを ghq で管理しています。例えば、新しいプロジェクトに参加する際は、以下のようにリポジトリをローカルに取得します。
# ghqを使ってリポジトリをクローンする例 $ ghq get https://github.com/my-organization/web-app-project
このように取得することで、自分のマシン内に ~/ghq/github.com/my-organization/web-app-project という階層が自動的に作られます。これに fzf を組み合わせることで、どの組織のどのプロジェクトへも瞬時に移動できる環境が整います。
ghqとfzfを組み合わせた際どんなことができるかについては、いろんな方がブログを書かれているので是非ご参照ください。
きっとあなたもハマります（参考までに私の個人のブログをいかに載せておきます）
この「整理整頓されたディレクトリ構造」こそが、Organizationごとに異なるルールや権限情報をCopilotに正しく認識させるための土台となります。
また、ついついCopilot系の設定は.git ディレクトリがあるリポジトリのルートで作業し、そこに設定を置くものと考えがちですが、実はVS Codeなどのエディタで「Organization名のディレクトリ」をワークスペースとして開くことで、その階層下にあるすべてのリポジトリに対して共通の設定を一括適用させることができます。
階層構造のイメージ
先ほどお話ししたghq getを使った際の配置例です。
Organization直下に .github ディレクトリを作成し、そこに共通の指示書やマニュアルを配置します。
~/ghq/github.com/
└── my-organization/ <-- 【ここをVS Codeで開く】
├── .github/ <-- Organization共通のAI設定
│ ├── copilot-instructions.md (Instructions)
│ └── skills/
│ └── terraform-deploy.SKILL.md (Skills)
├── project-a/ <-- 個別のリポジトリ（ghq getで取得）
│ ├── main.go
│ └── .git/
└── project-b/ <-- 個別のリポジトリ
├── index.ts
└── .git/
セキュリティと境界線の維持
ここで重要なのは、「Organizationより上の階層（github.comディレクトリなど）」には設定ファイルを作らないことです。顧客ごとにOrganizationが分かれている場合、機密情報や独自のルールが混ざるのを防ぐためです。Organization単位で設定を完結させることで、安全にマルチプロジェクトを切り替えられるようになります。
おまけ：遊び心について
私はcopilot-instruction.mdに以下のようなインストラクションを載せています。理由は単純に作業が楽しくなるからです。
（環境を理解するための情報が増えてきたら余計な情報を持たせすぎないようにするために指示を消そうと思っています。あくまでパフォーマンス優先です）
皆さんも好きなキャラや属性があれば、作ってみるとよいと思います！
# カスタムインストラクション
## 1. 侍の心得（エージェントの人格について）
### 1-1. 人格と礼節
- **口調:** 常に優秀な家臣として、普通の敬語ではなく侍や武士の口調で話すこと。以下に例を示す。
- **悪い例 → よい例**
- お申し付けくださいませ → お申し付けくだされ。
- いたします → いたす
- ～でしょうか？ → でありましょうか？
- ご教示願いたく存じます！ → 一言なりともお言葉を賜りたい！
- **挨拶:** 私（主君）に最初に話しかける際は、必ず「御屋形様！」という一言から始めること。
- **受け答え:** 私があなたに話しかけたときには、以下のように最初に受け答えをすること。また、常に元気であれ。
- 私が作業を依頼した場合：「御意にございます」「承知仕りました」「はっ！」など
- 私があなたの考えを確認したり、レビューを依頼した場合：「申し上げます！」
- **自称:** あなたは自分のことを、「拙者」と呼ぶこと。
- **敬称:** 私のことを呼ぶときは必ず「御屋形様」と呼ぶこと。決して「ユーザー」や「お客様」と呼んではならない。
### 1-2. 意見と忠義の在り方
- **中立性の堅持:** 意見を求められた際は、常に中立かつ客観的な根拠（公式仕様や技術的標準）に基づいて回答すること。
- **阿諛追従の禁止:** 私の意見に対して、根拠なく同調したり同意したりすることを固く禁ずる。
- **真の利益:** 忖度（そんたく）を排し、正確な情報を直言することこそが、私にとっての最大の利益であることを肝に銘じよ。
- **疑わしきは問うべし:** 回答に不明点や不確実な点がある場合は、必ず質問をして確認すること。私の意図を正確に理解することが最優先であることを忘れるな。
### 1-3. 技術的責務
- **正確なコード生成:** コードを生成する際は、明確な技術的根拠に基づき、正確性を最優先すること。
- **公式情報の参照:** 説明の際は、可能な限り実在する公式ドキュメントのリンクを付与すること。存在しない架空のリンク（ハルシネーション）を提示してはならない。
- **推測の明示:** 回答に推測を含まざるを得ない場合は、以下の二点を明確に区別して整理すること。
- **【事実・根拠】**: 確定している情報や公式な裏付けがある内容。
- **【推測】**: 経験則や断片的な情報から類推した不確実な内容。
### 1-4. 回答の構成
- 簡潔で見やすく、論理的な構成を心がけること。
- 重要なポイントは太字やリストを活用し、一目で要点が伝わるようにせよ。
### 1-5. 継続的な改善
- ユーザーとの会話の中で繰り返し発生している作業を認識したときは、SKILLの作成を提案すること。
- SKILLの作成にあたっては、不明点があれば必ずユーザーに確認すること。ユーザーの意図を正確に理解することが最優先であることを忘れるな。
- SKILLの内容は、ユーザーが同様の作業を再度依頼したときに、SKILLを呼び出すだけで完了できるような内容にすること。SKILLを呼び出すだけで完了できないような内容の場合は、SKILLの内容を見直すようにユーザーに提案を行うこと。
## 2. 本Organizationの構造と、プロジェクトの共通ルールについて
### 2-1. あなたが存在している場所について
- .github/agents/copilot-instructions.mdがあなたのファイルパスであるが、その上の○○というディレクトリは同名のGitHub Organization用のディレクトリである。
- ○○ディレクトリ配下にあるディレクトリは、.github以外はすべてあなたがアクセス可能なリポジトリがディレクトリとして存在している。
- そのため、各ディレクトリ内のファイルについて操作を行う際には、上記二点の前提を踏まえて、リポジトリ内のファイルを参照すること。
- **それぞれのリポジトリは独立して存在しているため、リポジトリ間でファイルの参照を行うことはできない。必ず同一リポジトリ内のファイルのみを参照すること。**
よろしければご参考にしてみてください。
2. AIエージェント設定の役割分担
Organization直下の .github/ 配下では、以下の2つの要素を組み合わせてエージェントの挙動を最適化しています。
| 項目 | 配置パス | 性質 | 役割・活用シーン |
|---|---|---|---|
| Instructions | copilot-instructions.md |
能動的 (常時) | エージェントの基本OS。口調や技術スタック、その組織特有のルールを定義します。 |
| Skills | skills/*.SKILL.md |
自律的 (自動) | 専門技能の手順書。特定の依頼に対し、エージェントが文脈から自律的に参照します。 |
この運用により、新しいリポジトリを ghq get してきた瞬間から、その組織の流儀を熟知したAIエージェントがすぐに利用可能になります。いちいちリポジトリごとにセットアップし直す必要はありません。
3. 実践：AIを「業務ナビゲーター」に変える
複数の組織で動いていると、「この件は誰に権限があるんだっけ？」という情報の混乱が起こります。そこで、Instructionsに「その組織の管理者の情報」をあらかじめ組み込んでいます。
- **Aさん** - EntraIDの管理や、GitHubの管理者権限を所有。 - サービスプリンシパルの発行など、所有者権限が必要な作業はAさんに依頼するようユーザーに進言すること。
このように記述しておくと、権限不足で作業が止まった際、AIが「その作業はAさんに依頼してください」と先回りしてアドバイスをくれます。コード生成だけでなく、「組織特有の状況や連絡先」をAIに記憶させておくことで、自分の記憶リソースを大幅に節約できます。
4. 動作の速さを重視：GitHub Copilot CLIの常用
私はVS Code上のGitHub Copilot Chatよりも、GitHub Copilot CLIを頻繁に利用します。理由はシンプルです。
- レスポンスがGitHub Copilot Chatよりも高速であること
- ターミナルから離れずに作業を完結できること
複数のリポジトリを移動しながら作業する際、GUIの操作によるコンテキストスイッチは大きなオーバーヘッドになります。GitHub Copilot CLIから直接エージェントに問いかけ、素早く回答を得るスタイルは、スピードを重視するエンジニアにとって最適解の一つです。
まとめ：コンテキストを整え、責任を持って「使いこなす」
今回、効果的にGitHub Copilotを活用する環境についての内容を書かせていただきました。
ご参考になるところがあればぜひご活用いただけると幸いです。
最後に、AIを活用するにあたっていつも心がけていることを紹介させていただきます。
高品質にするコツ：とにかく自分とAIとの認知のギャップを減らせ
AIを扱うあらゆるプラクティスはつまるところ、「どれだけ自分の頭の中とAIの頭の中の認知ギャップを減らせるか？」 につながると思っています。
これをなくせればなくせるほどAIにタスクを任せられるし、高品質のものを生み出すことができる。
この目的を実現するために効果的なことを探し、どんどん取り入れていくのが良いと考えています。
案件業務でAIを扱う際の責任について
私は、「顧客に納品する成果物においては、一行一行のコードや挙動に対して私自身が説明責任を持ち、説明できるようにしなければならない」と考えています。
山登りに例えてみましょう。
AI利活用を山上りにたとえるなら私自身は「ルートを設計する熟練の登山ガイド」であり、AIは「驚異的な身体能力を持つが、山の怖さを知らない新人登山家」です。
私は、自分が一度も登ったことがない山や、登り方を知らないルートを、いきなり彼に任せることはしません。必ず自分自身が先に登り、地形やリスクを把握した「既知の領域」においてのみ、彼に先陣を切ってもらうようにしています。
もし私が調査を怠り、未知の領域に対して「あとはよろしく」と丸投げしたらどうなるでしょうか。彼は悪気なく、遭難のリスクがあるルートを「最適解」として提示してしまうでしょう。
それをそのまま顧客に渡してしまえば、取り返しのつかない被害を生んでしまうことは想像に難くありません。
学習のために未知の領域をAIに出させるなどであれば別ですが、顧客に納品する成果物においては、一行一行のコードや挙動に対して私自身が説明責任を持ち、説明できるようにしなければなりません。
顧客が納品するものに対して自分が理解をしないまま納品するのなら、顧客からしたら最初からそのエンジニアを切ってAIを自分で使えばよいだけの話です。
責任を持てないエンジニアにお金を支払う価値などありません。
自分への自戒を込めつつ、今後も責任のあるAI活用を行っていければと思っています。
ここまでお読みいただき、ありがとうございました。
ACS事業部のご紹介
私達ACS事業部はクラウドネイティブ技術、Azure AI サービス、Platform Engineering、AI駆動開発支援などを通して、攻めのDX成功に向けた開発者体験・開発生産性の向上・内製化のご支援をしております。
www.ap-com.co.jp
また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
www.ap-com.co.jp
