ども！最近は VS Code のターミナルとチャット欄だけで一日が終わる龍ちゃんです。
生成 AI を使った開発、爆速ですよね。コード書いて、テストして、コミットして。エディタの中で AI と会話しながら全部完結します。この体験を知ってしまうと、もう戻れないんですよ。
爆速になりつつ品質をいかに担保するのか？というのが直近の大きな課題です。
作業が途切れる瞬間がある
ただ、途切れる瞬間があるんですよね。CI が落ちたらログを確認しないといけないし、コードを Gist に保存したくなることもある。GitHub でやりたいことが出てくるたびに、ブラウザを開いてしまうんです。その瞬間にエディタから手が離れてしまいます。
たかが数分のことなんですけど、集中してたのに一回途切れるあの「うっ」って感じ、ずっと気になってました。
よく考えると、ブラウザを開いてまでやってることって CI のログを読むとか、Gist にコードを貼るとか、そういうことなんですよね。中身はぜんぶテキストです。テキストとして手に入ればそれでいいのに、わざわざブラウザの UI をポチポチ…
この記事は、VS Code でコード書いてて、GitHub のためにブラウザに飛ぶたびに「うっ」ってなる人に向けて書いています。
「ちょっとブラウザ開くだけ」がどれだけ重いか書き出してみて、それを解決する方法として gh CLI（GitHub CLI） や MCP にどんな選択肢があるか整理して、実際にどう変わるのかを具体例で見ていきます。
ブラウザを開く「ちょっとだけ」が重い理由
「ちょっとブラウザ開くだけ」。実際にちょっと開くだけです。でも、実際にやってることを書き出してみると、ちょっとじゃないんですよね。
CI が落ちたときの「ちょっとだけ」
GitHub Actions の CI が落ちたとき、ログを確認するまでの手順を書き出してみます。
- ブラウザで GitHub Actions の Run ページを開く
- 失敗したジョブを展開する
- エラーログの該当箇所を探す
- ログをコピーする
- VS Code に戻る
- コピーしたログを読んで原因を調べる
6ステップもあります。「ちょっとだけ」とは一体何だったのか。
Gist に保存したいときの「ちょっとだけ」
Gist も似たようなもんです。
- gist.github.com をブラウザで開く
- ファイル名を入力する
- コードを貼り付ける
- description を書く
- public / secret を選択する
- 「Create gist」ボタンを押す
こちらも6ステップです。逆方向、つまり Gist からコードを取ってくるときも同じぐらいかかります。
ステップ数が問題じゃない
ただ、正直に言うとステップ数自体はそこまで大した話じゃないんですよね。慣れてれば数分で終わります。
問題はそこじゃなくて、作業の流れが切れる ことなんです。
コード書いてる最中にブラウザに飛んで、用が済んでエディタに戻ってくる。たかが数分です。でも戻ったときに「何してたっけ」「どこまでやったっけ」ってなりません？ エディタの画面は変わってないのに、頭の中の作業文脈がリセットされてるんですよね。さっきまで集中してた「あの感じ」を取り戻すのに、また時間がかかります。
これだけでもダルいんですけど、生成 AI と会話しながら作業してるときはもっとキツくなります。コードの修正を進めてる最中にブラウザに飛ぶと、戻ってきてからさっきの続きを取り戻すのに時間がかかるんですよね。頭の中を巻き戻すだけじゃなくて、ブラウザで確認してきたログの内容をいちいち説明し直さないといけない。あの手間がほんとにダルいんですよ。
結局、ブラウザの GUI で得られる情報って、テキストで十分なものばかりなんです。CI のログも Gist のコードも、テキストとして手に入ればいい。それならエディタの中で完結させたいんですよね。
gh CLI・MCP・Claude Code Skills — エディタから GitHub を操作する方法
「エディタの中で GitHub の操作を呼び出したい」——この望みを叶えてくれる方法は、実はいくつかあります。
GitHub CLI（gh コマンド）
GitHub CLI は、GitHub が公式に提供しているコマンドラインツールです。gh run list で CI の実行一覧を取得したり、gh gist create で Gist を作成したり、ブラウザでやっていた操作がターミナルのコマンドで一通りできるようになります。
VS Code のターミナルから実行すれば、ブラウザを開く必要がなくなります。情報はテキストで返ってくるので、そのまま読めるし、AI に渡すこともできます。--json や --jq で出力形式を絞れるので、必要な情報だけを取り出しやすいのも強みです。
認証の補足: とりあえず試すなら
gh auth loginのブラウザ認証が手軽です。運用するなら PAT（Personal Access Token）で必要なスコープだけに絞るのがおすすめです。認証方法の詳細は各編で触れます。
MCP（Model Context Protocol）
MCP は、AI ツールが外部の API を呼び出すための仕組みです。GitHub MCP Server を設定すると、AI が直接 GitHub の API を叩いてくれます。Issue の操作やリポジトリの情報取得など、カバー範囲は広いです。
ただし、ツールの戻り値が大きくなりがちで、トークン消費が膨らみやすいという特性があります。また、Gist 関連のツールは 2026年2月時点では提供されていません。
Claude Code Skills
Claude Code の Skills を使うと、コマンドの手順を Markdown ファイルに書いておくだけで、チャットから呼び出せる仕組みを作れます。gh CLI の手順を書いておけば、「CI 失敗してるから見て」と打つだけでスキルが gh CLI を実行してログを取得し、Claude が分析する——という流れをチャットの中で完結させられます。
このシリーズのアプローチ
どの方法を使っても「エディタから離れない」という目的は達成できます。
このシリーズでは gh CLI + Claude Code Skills の組み合わせを選びました。CLI なら出力形式を自在に絞れるのでトークンを無駄遣いしにくいし、SKILL.md に書く手順も Bash コマンドそのままなので設計しやすかったんですよね。選んだ理由の詳しい話は各編で触れますが、大事なのは方法論よりも「エディタから GitHub の操作を呼び出せるようになる」という体験のほうです。
シリーズ構成
GitHub Actions をよく使うなら CI 編から、スニペット管理や Gist 活用が気になるなら Gist 編から読むのがおすすめです。
gh CLI × Claude Code Skills で何が変わるか
じゃあ、実際にどう変わるのか。各編の内容から1つずつ味見してもらいます。
CI の場合
エディタのチャット欄で「CI 失敗してるから見て」と打ちます。
スキルが失敗した Run を探して、ログを取得して、Claude が分析結果を返してくれます。
## Failure Analysis
**Run:** #22430458939 - Demo - Failure Workflow
**Failed Jobs:**
| Job | Error Summary |
|-----|--------------|
| Test | integration test で AssertionError（期待 200、実際 503） |
**Root Cause:**
test_pipeline.py の test_full_pipeline テストで、
API レスポンスのステータスコードが期待値 200 に対して 503 を返している
**Suggested Fix:**
- テスト対象の API サーバーが起動しているか確認
ブラウザは一度も開いていません。Run を探す → ジョブを展開する → ログをコピーする → 原因を調べる、という6ステップが「CI 失敗してるから見て」の一言に置き換わっています。そのまま「じゃあ直して」と続ければ、修正まで会話の流れの中で進められます。
CI 編: 失敗ログの取得から修正まで VS Code で完結させる仕組みと作り方。SKILL.md の設計やトークン効率のルールも紹介します。
Gist の場合
「Python のスニペット取ってきて」と打ちます。
スキルが Gist を検索して、ファイルを特定して、中身を取得してくれます。
"""Python useful snippets - よく使うコードスニペット集"""
# --- flatten nested list ---
def flatten(nested: list) -> list:
...
gist.github.com は開いていません。検索してコードをコピーしてエディタに貼り付けて……という手順がまるごとなくなっています。
保存も同じです。コードを書いてて「これ Gist に保存しといて」と打てば、ファイル名も description もいい感じに付けて保存してくれます。URL が返ってくるので、共有したければそのまま貼るだけです。
Gist 編: 「保存して」「取ってきて」で Gist 操作が完結する仕組みと作り方。CRUD をスキル化するときの安全策（secret デフォルト、削除前確認）も紹介します。
まとめ
ブラウザに飛ぶたびに作業の流れが切れる。ステップ数じゃなくて、頭の中の文脈がリセットされるのがキツいんですよね。CI のログも Gist のコードも、テキストとして手に入ればそれでいいんです。
gh CLI や MCP を使えば、エディタの中から GitHub の操作を呼び出せます。Claude Code Skills と組み合わせれば、チャットの一言で全部完結します。仕組み自体は .claude/skills/ に Markdown ファイルを1つ置くだけなので、自分のプロジェクトに合わせてカスタマイズしやすいのもポイントです。
このシリーズでは gh CLI + Skills の組み合わせで2つのスキルを作りました。各編では SKILL.md の全文と設計の考え方を解説しているので、そのまま使うこともできるし、自分のプロジェクトに合わせてカスタマイズすることもできます。CI と Gist に限らず、gh CLI でできる操作なら同じパターンで横展開できるので、「自分のプロジェクトだとこの操作が面倒」というものがあれば、各編のやり方を参考にスキルを作ってみてください。
ではまた！
