GitHub CopilotのCanvas機能と開発現場の判断基準

AIにコードを書かせる時代から、僕らの「判断基準」を教え込む時代へフェーズが変わった。

プロンプトを工夫しても満足なコードが出ない原因は、AIの性能ではなく、開発者自身の頭の中にある「言葉にできていない盲点」にある。

最新のAI開発現場では、作業時間を半分以下に減らすチームが続出している。

従来は1時間かかっていた判断作業も、AIが5分で出した候補を人間が10分でチェックする合計15分の工程に置き換わっている。

GitHub CopilotのCanvas機能や最新エージェントの動向から、エンジニアがAIに「インストール」すべき要素を深掘りする。

視覚的な作業空間と判断の自動化

開発ツールとAIモデルの使い方が、ここ数ヶ月で次のフェーズへ入った。

GitHubはCopilotにCanvas機能を投入した。

AIと視覚的に作業を進めるワークフロー統合へと舵を切っている。

Anthropicのエンジニアが明かしたプロンプト構築の知見も注目されている。

最新モデルで出力の質を決めるのは、モデルの性能差ではない。

人間が自覚できていない未知の未知（Unknown Unknowns）を、いかにAIに洗い出させるかだ。

自身の知識の盲点を特定させる「ブラインドスポットパス」という手法が、コード設計の初期段階で使われている。

実際の現場でも、単なるコード生成を超えたAIの組み込みが進む。

映像制作の現場では、WhisperとMCPサーバーを連携させた自動編集が動いている。

固有名詞の認識率を上げるため、音声と一緒にタイトルや登壇者などのテキスト情報を渡す工夫が取られている。

手作業でのカット編集なら1時間かかっていた工程が短縮された。

AIによる下処理に5分、人間のチェックと微調整に10分、合計でわずか15分という処理時間が実現している。

しんたろー：
1時間かかっていた作業が15分で終わる状況が気になる。Claude Codeで1人SaaSを作っているが、指示出しの巧さより、自分の頭の中にある「譲れない判断基準」をどれだけ言語化できるかが勝負だ。

作業時間の比較データが変化の激しさを物語る。

* 3時間の音声の文字起こし：手作業で180分 → AIの自動処理で0分

* 動画のカット編集とチェック：手作業で60分 → AIと人間の連携で15分

人間がゼロから作業する時代は終わった。

AIが出してきた一次アウトプットに対して、人間がフィルターとして判断を下すスタイルが定着している。

AIに適切な判断を行わせる鍵は、プロンプトの工夫だけではない。

SKILL.mdやCLAUDE.mdといった専用の管理ファイルに、プロジェクトごとの判断基準を蓄積する。

新人を教育するように判断ロジックをファイルへ書き足していく。

教えた基準は確実に蓄積され、チーム全体の共有資産として機能する。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

AI開発のボトルネックはモデルの能力から「未知の未知」へ

AIにコードを書かせる時代から、AIに判断基準をインストールする時代に入った。

この変化の本質を理解しなければ、最新のAIツールを導入しても開発スピードは上がらない。

以前のAI活用は「どう指示を出せば狙い通りのコードを書いてくれるか」というプロンプトのテクニックが中心だった。

AIの推論能力が向上し、作業そのものはAIが数分で終わらせる。

新しく浮き彫りになった壁が、開発者自身の盲点だ。

いわゆる未知の未知（Unknown Unknowns）と呼ばれる領域である。

自分が「何を知らないのかすら分かっていない状態」のままAIに指示を出すと、AIは一般的なベストプラクティスを回答する。

実際のプロダクト開発には、既存コードの制約やドメイン固有のルール、過去の技術的負債など、表に出てこない前提条件が無数に存在する。

AIの出力が期待とズレる原因は、モデルの性能不足ではない。

開発者が自分の中にある暗黙知や考慮漏れを、AIに共有できていないことにある。

この課題に対して、海外の最前線では二つのアプローチがせめぎ合っている。

一つは、ツール側のインターフェースを拡張するアプローチだ。

作業空間や連携の仕組みを整えることで、AIと人間の作業文脈をツール全体で統合する。

もう一つは、プロンプトの段階で開発者のメタ認知を強制するアプローチだ。

コードを書かせる前に「この実装における僕の未知の未知を特定してくれ」とAIに依頼し、思考の抜け漏れをあらかじめ潰してから実装に入る。

ツールでワークフローを包み込むか、開発者の思考の盲点をAIに突かせるか。

アプローチは異なるが、目指しているゴールは同じだ。

AIを同じ前提と判断基準を持つチームメンバーに育てることである。

しんたろー：
AIに「僕の盲点を教えて」と頼むと、自分の無知を突きつけられる。コードを書いてからエッジケースに気づいて修正するより、実装前に潰す方が効率的だと感じている。

個人でのSaaS開発においても、この「判断基準の伝達」が日々の開発効率を左右する。

Claude Codeを使って開発を進める際、毎回同じ指摘をプロンプトで繰り返すのは時間の無駄だ。

AIが意図と異なるコードを出力した時は、その場で修正させるだけで終わらせない。

「なぜその実装ではダメなのか」「うちのプロダクトではどういう設計思想を優先するのか」を言語化し、プロジェクト内の設定ファイルに書き足す。

具体的には、SKILL.md や CLAUDE.md といったファイルに判断ルールを蓄積する。

「エラーハンドリングは特定のエラークラスに集約する」

「パフォーマンスよりもコードの可読性を優先する」

こうした頭の中にしかなかった暗黙知をテキストとしてファイルに保存する。

次からのセッションでは、AIはそのSKILL.mdを参照し、最初から基準に合致したコードを出すようになる。

これは従来の開発ツールの設定をいじる作業とは根本的に異なる。

自分の価値観や開発方針を、AIという相棒にインストールしていく感覚だ。

エンジニアに求められる役割も変わる。

これまでは「コードを素早く書く力」や「構文を暗記していること」が価値だった。

しかし、コードの生成速度や量の勝負では、人間がAIに勝てる要素はない。

これからのエンジニアの市場価値を決めるのは、以下の3つの能力だ。

* プロダクトにおいて「何が良い状態か」を定義できる品質の判断力

* 自分の知識の限界を自覚し、AIに盲点を指摘させるメタ認知能力

* 自身の暗黙知をSKILL.mdなどに構造化して渡せる言語化能力

AIは爆速で候補を出力するが、そのコードを採用するかどうかの責任は取れない。

最終的に「このコードで本番環境にデプロイする」と決断し、品質に責任を持つのは人間だ。

ゼロからコードをタイピングする作業者から、AIのアウトプットを評価し、基準を教え込む教育者へ。

この役割の転換を受け入れた開発者から、1人でも巨大なプロダクトを動かせる領域へ足を踏み入れている。

明日から開発現場で変えるべき3つのこと

コードをタイピングし始める前の準備とフィードバックのやり方を変えるだけでいい。

AIの出力を変えるために、明日から試せる3つの具体的なアクションがある。

1つ目は、リポジトリのルート直下に判断基準を集約したテキストファイルを設置することだ。

Claude Codeを使うならCLAUDE.md、各種エージェントツールならSKILL.mdといった専用ファイルを準備する。

ここには「単体テストの命名規則」や「ファイル構造」だけでなく、「コードの可読性と実行速度のどちらを優先するか」「絶対に使ってはいけない非推奨のライブラリ」といった価値判断の優先順位を箇条書きで残す。

プロジェクト固有の文脈をAIに事前インストールしておく場所を作る。

2つ目は、新しい機能を実装する直前に盲点のあぶり出しをAIに依頼することだ。

いきなり「この機能を実装して」とプロンプトを投げるのをやめる。

「この機能を実装したいが、僕が気づいていない技術的な落とし穴や設計上の盲点（Unknown Unknowns）を箇条書きで挙げてくれ」と事前に質問する。

AIはリポジトリ全体を高速でスキャンし、データベースの制約や認証の依存関係をたった5秒で指摘する。

しんたろー：
Claude Codeに不具合の理由を伝えてCLAUDE.mdを更新する作業は、未来の自分への投資だ。翌週に同じミスが発生して虚無になる時間をゼロにできる。

3つ目は、AIが出してきたコードがダメだったとき、修正理由を言語化してログに残すことだ。

単に生成をリトライしたり「やり直し」とだけ伝えるのは効率が悪い。

「この実装だと本番環境のメモリを圧迫する。うちの設計では〇〇のキャッシュ処理が必要だから、次回からはこの手順を守って」と理由を教える。

そしてその対話内容を、そのまま先ほどのルール用ファイルに書き加える。

このフィードバックのループを回すと、AIはわずか数日で自社の開発ルールを熟知した専任エンジニアのように振る舞うようになる。

結果として、手作業でコードを書いていた実装の拘束時間を70%削減できる。

余った時間は、プロダクトの仕様検討やユーザー体験のブラッシュアップに充てる。

AIを単なる「自動生成ツール」として扱うか、「判断基準を共有するパートナー」として育てるか。

この小さなスタンスの違いが、今後の開発スピードに差を生む。

よくある質問

AIに「判断基準」をインストールするとは具体的にどういうこと？

AIが実装で迷った時に参照すべき優先順位やNG行動を専用ファイルに書き込んでおくことだ。

例えばコードレビューなら「可読性優先か、実行速度優先か」といった基準をMarkdownファイルに箇条書きで定義する。

開発者自身の価値観や暗黙知を構造化して渡すことで、AIの出力は実戦レベルへ引き上がる。

自分の盲点である「未知の未知」をAIに見つけてもらうコツは？

自分の知識の限界を認めた上で、思考の穴を指摘させるプロンプトを投げるのが効果的だ。

「このモジュール周辺の仕様に詳しくない。僕が見落としているリスクや未知の課題を洗い出してほしい」と依頼する。

AIの膨大な知識ベースを探索させることで、人間単体では気づけない設計の落とし穴を実装前に特定できる。

AIに渡すルールが多すぎて指示が競合した場合はどうすればいい？

すべての判断基準を1つのファイルに詰め込むと、AIの文脈理解が圧迫されて精度が落ちる。

全体に適用する「共通ルール」と、特定の機能でのみ使う「個別ルール」でファイルを分割して管理するのが鉄則だ。

定期的にAIの回答傾向をチェックし、古くなった指示や矛盾するルールを削るメンテナンスを習慣にする。

まとめ

AIを作業員として使うフェーズは終わった。

これからは、自分の中にある判断基準や暗黙知をどれだけ言語化できるかで開発速度に数倍の差がつく。

AIに思考ロジックをインストールして、判断の精度を上げていこう。

僕もClaude Codeで判断ルールを積み上げているが、作業の指示出しが消えて本質的な開発に集中できている。

自分の判断基準をAIと共有して運用の負荷を減らしたいなら、まずは自動化の仕組みを作ってみるのがおすすめだ。

👉 ThreadPostでSNS運用を自動化する