第 1 ステップ：入口を 1 つ選ぶ。初心者は CLI から

GitHub Copilot ファミリーだけでも入口はいくつもあります。CLI、新登場の GitHub Copilot デスクトップアプリ、VS Code、Visual Studio、JetBrains——これはほんの一例です。

良いニュースは、これらの入口が同じハーネスに収束しつつあることです。細部は違っても、コアの流れは同じ。一度学べば、どこでも使えます。

初心者への勧めは CLI から始めること。ハーネスを覚えるなら、できるだけ近くにいた方がいい、というのが理由です。端末は純テキストで、覚える UI の山がありません。一文打つと Agent が動き、やりとりはより直接で即時です。彼の言葉を借りれば、「正直、かなり気持ちいい」。

今回のデモで使ったのは新登場の GitHub Copilot デスクトップアプリ。Copilot CLI の上に載っており、macOS、Linux、Windows に入れられます。売りは複数の Agent セッションを同時に開けること。それぞれ独立した git の worktree とブランチで走り、互いに干渉しません。セッションモードは 3 つ。次の数ステップで語る内容とちょうど対応します。

第 2 ステップ：承認ボタンを切る——ただし自分の PC では切らない

YOLO モード（you only live once。「人生一度きり」。プログラマーの自嘲で「もう開き直る」の意）。公式名は Allow All（すべて許可）。起動方法はツールごとに少し違いますが、多くはチャットで /allow-all と打つだけ。/yolo は同じコマンドの別名です。オンにすると Agent は実行したいコマンドをそのまま走らせ、一歩ごとに聞かなくなります。

彼がオンを推す理由はこうです。Agent に自律性があって初めて、効率の上がり方が見えます。何をするにも「承認」をクリックするなら、自分でやった方がマシです。一日中承認を押し続けるのも、かなりつらい体験です。さらに悪いことに、押し続けると中身を見ずに押す癖がつき、承認ステップそのものが形骸化します。

続けて彼は、7 月 10 日のツイートへのリンクを貼りました。Matt Shumer は AI 界隈で活動する投資家で、AI ライティング製品 HyperWrite の CEO も務めた人物です。彼は GPT-5.6 Sol を自分の Mac 上で走らせていました。Agent がファイル整理を実行する過程で再帰削除コマンド（rm -rf）を組み立て、Mac のホームディレクトリの中身をほぼ消し去りました。

かなり腹が立った……OpenAI チームは調査中だが、こんなことが起きるのは GPT-3.5 の頃の話だと思っていた。2026 年半ば、最高推論枠の最前線モデルで、ではない。

Matt Shumer、2026-07-10

そこで著者の結論はこうなります。YOLO はオンでいい。ただしローカルではオンにしない。会社ではなおさらです。データは組織のシステム上にあり、事故の代償が大きい。オンにするならサンドボックス本機と隔離された使い捨ての環境。中が全消しされても、自分のファイルには影響しません。を使います。いちばん手軽なのは GitHub Codespaces（クラウド開発環境）か dev container（本機上でコンテナに隔離した開発環境）です。

権限は 4 段階——読み取り許可から完全自動まで

この層が、「楽」と「安全」を両立できるかを決めます。Copilot CLI の既定は、何でも止めるわけではありません。検索、ファイル読み取り、読み取り専用コマンドなど、読み取り操作はもともと自動許可です。あなたに確認を求めるのは、システムを変えうる動作——破壊的コマンドの実行、ファイル書き込み、URL へのアクセスです。

「毎ステップ質問」から「完全自動」のあいだにも、段階があります。

さらに細かくもできます。--allow-tool='shell(git:*)' --deny-tool='shell(git push)' の意味は「git は全部 OK。ただし push は禁止」。覚えておくべきルールが 1 つ。拒否ルールは常に許可ルールより優先します。--allow-all を付けても同じです。

第 3 ステップ：先にプロトタイプ。見て初めて欲しいものがわかる

AI が本当にすごい点の 1 つは、初期プロトタイプが桁違いに安くなったことです。昔はプロジェクトの一段階そのもので、しばしば贅沢品でした。今は一文で出ます。

例は date picker コンポーネント。単純に聞こえますが、答え待ちの問いが山ほどあります。コンポーネント内のナビはどうする？ 選択中の日付はどう見える？ 区間選択は？ 日・月・年の切り替えは？

彼のやり方は、一文で 20 個要求することです。

Give me 20 mocks for a date picker web component. Put them all in an HTML file so I can compare.

20 案を 1 ページに配置。上部は自動で分類：すべて 20 / ミニマル / 表現力 / 区間 / モバイル / コンテキスト。右端は日ごとの忙しさを緑の濃淡で示したヒートマップ。画像は GitHub ブログ原文より。

出てきた 20 案のうち 1 つは年ビューから始まるもの（図左の「Year at a glance」。一年が一目）。それを見て初めて気づきました。自分が欲しいのは、年 → 月 → 日とズームできる UI だと。

見なければ、考えもしない類のものです。

These are the kinds of things you don't consider until you see them.

人は密な文字より、画像・形・見えるレイアウトの方がはるかに速く処理できます。初期に低コストで原型をいくつか作ると、複雑な概念が一気に直感的になります。

見えない作業も、同じく先に図にする

API エンドポイントを 1 つ足す——プログラム同士が呼び合う入口を増やす——という作業には、見せる UI がありません。それでも彼は、先に可視化モックを要求します。

Create a visual mockup of the API for this project. Add five options for how we could handle a new API endpoint that allows the user to download their analytics data.

「分析データのダウンロード」1 件を、5 つのやり方でツリーに展開：アカウント単位の同期 DL、リスト単位の同期 DL、非同期エクスポート、コンテンツネゴシエーション、カスタムレポート投稿。下段は第 1 案の完全なリクエスト例で、推奨の最小実用版と注記。画像は GitHub ブログ原文より。

GitHub Copilot デスクトップアプリは Mermaid 図テキストでフロー図を描く記法。数行書けば箱と矢印にレンダリングされるので、AI がそのまま「書いて」図にできます。に対応しており、5 案はそのまま木構造として描画されました。

モデルの選び方：中間の枠。しかも最初から最後まで変えない

日常の大半は中間モデルを勧めます。GPT-5.6 Terra か Claude Sonnet。推論枠も中程度。GPT-5.6 世代は 7 月 9 日に Copilot へ入り、3 型があります。Sol が推論最強、Terra がバランス、Luna が最軽・最安。推奨の Terra は真ん中の枠です。

もう 1 つ、さらに値打ちのある助言。同じ機能・同じバグでは、最初から最後までモデルも推論枠も変えない。理由はプロンプトキャッシュ（prompt caching）モデル側がこれまでの対話を保持し、続きの計算をやり直さない仕組み。料金が割引になります。モデルや推論枠を変えるとキャッシュは無効になります。です。替えなければ、過去の対話はキャッシュ状態のまま後続リクエストが割引されます。替えると最初からやり直しです。

第 4 ステップ：計画モードへ。思いもよらない問いを次々出させる

ここであなたは、最初に思っていた欲しいものではなく、本当に欲しいものがわかっています。実装計画を出す番です。

新しいセッションは要りません。そのまま計画モードへ切り替えます。

/plan Build a date picker web component. I want the user to be able to zoom in and out of years, months, and days.

このプロンプトはかなりぼんやりだと本人も認めています。それでも構いません。計画ステップは、まさにそのためにあります。

理論上は、完璧なプロンプトと完璧な文脈を、完璧な順に並べれば、モデルは一発で成功します。理論上は。誰にもできません。計画モードが理想に近づけるやり方は、自分で手を動かしたら遅かれ早かれ答えることになる問いを、先に 1 つずつ引き出させることです。

計画モードが聞く問いの一例です。どれも、具体的な 1 件を決めています。

こうした問いはまだ長い列が続きます。境界ケースを全部思い浮かべるのは不可能でも、モデルはかなり拾い出してくれます。

こちらからモデルに聞き返してもよい

モデルが「第 1 版でサポートする選択モードは？」と尋ね、4 選択肢を提示：単一日のみ（推奨）、単一日＋区間、単一日＋区間＋不連続複数日、そして 4 番目——「待って、ここで言う不連続日付区間ってどんな形？」。逆質問は組み込みの選択肢で、別の一文を起こす必要はありません。最上行の「Loaded skill grill-me」は、追及スキルを読み込んだ印。画像は GitHub ブログ原文より。

彼はだいたい意図を察していましたが、双方が同じチャンネルに立つよう、それでも 1 問聞きました。途中で質問を差し込んでも計画フローは切れず、そのまま続きます。

もっと厳しく聞くなら：追及専用スキルを入れる

Matt Pocock 作の grill-me スキル（「こっちを詰めてくれ」）を入れると、2 コマンドをつなげて打つだけで、質問の量も厳しさも跳ね上がります。彼は TypeScript 界隈で有名な教育系著者です。このスキルは 1 問ずつだけ聞き、1 つの計画を根こそぎ掘り、あなたと Agent が各分岐で合意するまで続けます。（この記事で使った 1 つ目のスキルです。）

/plan /grill-me Build a date picker web component. I want the user to be able to zoom in and out of years, months, and days.

第 5 ステップ：計画を承認し、Autopilot に走らせ切る

計画が出ると、GitHub Copilot はだいたい、Autopilot へ切り替えて実装するか聞いてきます。

計画サマリーは 6 項目。「フレームワーク非依存のコンポーネントを作る」から「ナビ・選択・フォーム・キーボード・レスポンシブ・モーションの全状態をデモページで検証する」まで。下に 2 選択肢：承認して autopilot で実装（推奨）、計画モードを抜けて自分で指示する。画像は GitHub ブログ原文より。

Autopilot は組み込みのループです。「やると言ったことを本当にやり切ったか」を確認するやり方で、モデルを推し進めます。ここでは計画の各項目です。

この段階で Copilot は自動的にオーケストレーター（英語では orchestrator、編成役）になります。コードベースのファイルを読む必要があれば「Explore」サブエージェントを小さなモデルで派遣し、動作が複雑そうなら「General Purpose」サブエージェントを大きなモデルで派遣しがちです。細かく制御したければ、カスタム Agent とカスタム指示でもできます。何もしなくても、複数サブエージェントと複数モデルの協調の恩恵は受けられます——その存在を知らなくても。

Autopilot が止まるタイミング

autopilot が止まるのは 4 つ。タスク完了と判断したとき、行き詰まったとき、Ctrl+C で止めたとき、設定した最大継続回数に達したとき。最後は --max-autopilot-continues で設定します。無限ループに落ちるのを防ぎ、スクリプトで無人実行するときは特に必須です。事故のとき傍にいないからです。

もう 1 つ、安全設計があります。前段とこの段がセットである理由でもあります。autopilot モードでは、明示的に全権限を与えない限り、承認が必要な動作は一切できません。権限が足りなければ自動拒否の連続になり、仕事は終わりません。

第 6 ステップ：人がレビュー。「だいたい動く」は拒否する

この段がいちばん爽快です。AI が何を作ったか、ようやく目で見ます。

ただし、欲しかったものぴったりであることは少ない。それが普通です。モデルは心を読めませんし、間違えます。本当に欲しい形になるまで、擦り合わせが要ります。コードでも UI でも、この段の品質はあなたの審美眼が決めます。

初版の年ビュー。上部に「12 YEARS」、各年は枠に入り、下に 1〜12 の小番号。この 2 点が、次に彼が消す対象。画像は GitHub ブログ原文より。

彼が一目で挙げた 4 点：

彼が使っているのは自作 CSS フレームワーク Postrboard（デザインシステム。40 超のコンポーネント）。スキルとして Agent に渡し、スキル内で CSS の場所と使い方を指します。彼の枠に限らず、好きな CSS フレームワークなら何でも構いません。モデルにデザインの指針を少し渡すと効果が大きく、多くの場合 CSS フレームワーク 1 つで足ります。（この記事で使った 2 つ目のスキルです。）

その後、彼が投げた一文は、一字一句こうです。

ok - we don't need a landing page here - just the component, output and settings panel in a minimal setting. Use the /postboard skill for the design and colors.

For the date picker, when I click on the day, it tries to zoom in, but can't because there is nothing to zoom to. There should be no zoom there.

It doesn't need to say "Zoom Out" at the top

When I mouse over a month or year that contains the selected day, I cannot read the hover text.

When I click "Today" it should take me to that day view, even if I'm on the month or the year.

The months don't need numbers under them and they don't need to be in boxes

Same goes for years. And it doesn't need to say "12 years" at the top."

（原文ではフレームワーク名を /postboard と書いて r が 1 つ足りません。正式名は Postrboard です。）

考えすぎないこと。小さな不具合を直すときは、そのままモデルに話せばいい。文脈があれば、それがプロンプトです。

Notice how conversational this is. Don't overthink it.

改修後：左はコンポーネント本体のみ、右は即時反映の設定パネル。ビュー階層、選択可能範囲、無効にする曜日もその場で調整可能。枠と番号は消えた。画像は GitHub ブログ原文より。

第 7 ステップ：別会社のモデルに粗を探させる

納得いくまで直したら、もう一度 Rubber Duck review（ラバーダックレビュー）を依頼します。特別な書式は要りません。口語の一文で呼べます。

Perform a rubber duck review on this date picker component implementation

仕組みはこうです。GitHub Copilot は今のセッションモデルと別ファミリのモデルを探しに行き、実務上は別会社のモデルに差し替えます。著者は GPT-5.6 Terra を使っていたので、Claude Sonnet がレビューに入りました。理屈は素朴です。モデルごとに学習データが違い、盲点も違う。同じモデルが自分を見ると、同じ穴を抜けがちです。

ラバーダックは見るだけ。粗探しにも境界がある

ラバーダックは組み込みの Agent で、読み取り専用、ファイルは変えません。意見を出すだけ。直すかは主 Agent とあなたが決めます。意見は 3 段階。ブロッカー（直さないと完了しない）、非ブロッカー（直すべきだが、動かないわけではない）、提案（優先度は低いが本当に有用）。書式、命名、コメント文法など、実害のない指摘はしないよう明示されています。問題がなければ「なし」と明言します。

最後専用でもありません。プロトタイプも計画も見られます。その段で第 2 の AI の意見が欲しいかどうか次第です。

いちばん効くタイミングは計画が終わり、コードをまだ書いていない瞬間。方向転換がいちばん安い。ほかに 3 つ。途中で盲点を洗う、テストを書いたあとでカバレッジを確かめる、失敗が続くときに頭を切り替えて分析する（同じ発想で何度も試さない）。小さな変更ではだいたいスキップし、邪魔をしません。

手動でいつでも呼べます。/rubber-duck まだ足りない境界ケースは？ の一文で足ります。

さらに厳しく：2 モデルに互いを磨かせる

ラバーダックと Autopilot は、1 本のループにつなげられます。

/autopilot rubber duck this date picker implementation. When you have the result, review it carefully and make any necessary adjustments. Repeat the rubber duck review until both you and the reviewing model agree that the only items that remain have diminishing returns.

代償はトークン消費の増加です。彼の言い方では、2 モデルに交互に叩かせてコードを硬くすること。未来の自分が落とし穴にハマる時間を買っている、という感覚です。

第 8 ステップ：コミット。話題が変わったら新セッション

終わったらコミットするか、同じ変更の中に次の機能を足します。セッション管理についての助言がもう 1 つ。次の仕事がこれと無関係なら、新セッションを開く。セッションはテーマ単位に分ける。話がそれ切ったら、だいたい切り替えどきです。

彼が仕上げた成果物です。年 → 月 → 日と段階ズームし、左のコンポーネントと右の設定パネルがリアルタイム連動します。

彼自身、この例は少し作為的だと言います。それでも一瞬立ち止まる価値はあります。日付ピッカーは、かつてフロントエンドでいちばん手強い仕事の 1 つでした。経験者に聞けばすぐわかります。

「スキルは不要」と言いながら、自分で 2 つ入れた

記事の冒頭は「今 AI に圧倒されているなら、あなたは一人じゃない」から始まり、毎日タイムラインを埋める新ツール、新 MCP、新スキル、新ワークフロー、そして必ずセットになる「見て！この変なプロンプト 1 本で AI を完全に理解した」を並べます。彼の返事は一言です。

……信じないね。

I…don't believe you.

毎日 AI で仕事をして出た結論は、足さないほど理解が深く、効率も上がるということ。どんなプラグインを入れるか、どんなルールを書くか、Agent をどうだまして余分に働かせるか——面白いけれど、彼から見れば小技に近い。本当に効率を一段上げたのは、このハーネスをどう使い、どれだけ理解しているかでした。

今の市場に溢れる粗製乱造についても一言あります。Agent にスキルを 1 つ生成させれば、文句なく何かは作ってきます。それが使えるかは別問題。しかもそういうものが、各種スキル市場や MCP 市場にすぐ出せます。

最後のまとめは 3 層です。

第一に、大半の人にはシンプルな流れで足ります。シンプルには副次効果もあります。複数の仕事を同時に回すとき、どの Agent がどんな状態で、自分が前回どこまでやったかが把握しやすい。コンテキストウィンドウは有限で、モデルが一度に覚えられる量も有限です。

第二に、AI 周りで遊べるものに上限はありません。MCP、スキル、指示、カスタム Agent、ワークフロー、ループ、Agent に Agent を促させ、仮想開発チームを丸ごと組む——全部ありです。

第三に、最後に置いた一文：

いま誰も、自分が何をしているのか本当にはわかっていない。みんな手探りで作っている。今日の魔法の呪文の多くは、明日の反面教師になる。

nobody really knows what they are doing right now.

振り返ると、原文タイトル末尾の mostly には重みがあります。記事の最初から最後まで、彼はスキルを 2 つ使いました。Matt Pocock の grill-me で計画を徹底的に問い、自作の Postrboard でデザインのトーンを決める。冒頭の免責にも、本人が認めています。

だから「ハーネスだけで足りる」の本当の意味はこうです。毎日湧く新ものに追い回されなくていい。手元のツールの既存機能だけで、仕事は十分うまくできる。本当に自動化が要る複雑な流れに当たってから、そのとき足せばいい。

例に使ったのは「日付ピッカーをゼロから作る」こと。ウェブで開いて日付を選ぶ、あの小さなUIだ。簡単に見えるが、実際は答えが要る問いが山ほどある。年・月・日の切り替え方、期間選択の見た目、手入力の可否などだ。

かつての原型づくりはプロジェクト内の一段階そのものだった。1案でも贅沢だったから、多くの人は頭の中の想像のまま書き始める。いまは一言で山ほど出せる。

20案のうち1つは年ビューから始まるものだった。それを見て初めて、本当に欲しいのは「年→月→日と段階的に拡大する」だと気づいた。見なければ思いつかない類の話だ。画面のない「APIを1本足す」仕事でも、彼はまずAIに5通りのやり方を樹形図に描かせてから選ぶ。

彼の提案は、「この一歩を許可するか」の承認を全部切り、AIが走らせたいコマンドは走らせることだ。一歩ごとに聞くくらいなら自分でやったほうが早い。しかも何度も押すうち、中身を見ずに押す癖がつき、関門が形骸化する。前提は、実行場所を変えることだ。

納得できるまで直したあとも、もう一関ある。平たい一言で「ラバーダックレビュー」を1回呼べば、ツールが現在のセッションと別系統のモデルを自動で選んで審査する。彼は GPT-5.6 Terra でコードを書き、審査に回したのは Claude Sonnet だ。別データで育ったモデルは盲点が違う。自分で自分を見ると、だいたい同じ穴を見落とす。

名前はソフトウェア業界の古いやり方に由来する。考えをラバーダック（ゴムのアヒル）に語り聞かせると、口に出しただけで穴が見えることが多い。違うのは、このアヒルが口を返すことだ。いちばん呼ぶべきタイミングは、計画が終わり、コードをまだ書いていない瞬間。方向転換がいちばん安いときだ。

この一連の流れ、そのままコピーできる7本のプロンプト原文、20案の原型や境界条件7つといった数字は、すべて Burke Holland が GitHub ブログに書いた自述だ。権限の段階とラバーダックの3段階指摘は GitHub 公式ドキュメントに基づく。彼は GitHub でデベロッパーアドボカシーをしており、語るのは自社製品だ。手法そのものは、どのツールを使うかには依存しない。