AI開発の​差は​「速い​モデル」より​「速く​“安全に​”働ける​職場」で​決まる

技術ノート ｜ AI駆動開発の現場から

AIにコードを書かせる話になると、つい「どのモデルが一番速いか・賢いか」に目が行く。実際、2026年6月29日には Claude Opus 4.8 の fast mode が GitHub Copilot でプレビュー提供された。^[1] 賢さを落とさずに応答だけ速くする——反復の速いAI開発では、たしかに効く。けれど毎日AIにコードを書かせていると、もう一つの現実が見えてくる。

優秀で速いモデルを入れても、作業ブランチが混ざり、repoのルールを知らず、過去の判断を忘れ、危険なsetupスクリプトをそのまま実行し、UIのブランド文脈も持っていなければ、成果は安定しない。速いモデルは、散らかった職場では速く迷い、速く壊し、速くレビュー漏れするだけになる。

これは前回の続きの話だ。前回は「AI開発の主戦場はモデル比較から作業環境へ移った」という全体像を書いた。今回はそのサブテーマ——速いモデルが"安全に"働ける職場をどう作るかに絞る。私たち電脳技巧集団（AI職人ギルド）が受託開発でCodexやClaude Codeを毎日回している現場から、モデルを社員、職場を作業環境に見立てて整理する。なお外部ツールの数値・スター数は確認時点（2026-06-30）のGitHub・公式情報に基づくもので、CAGが独自に検証したものではない。

関連記事 ｜ 前回（全体像）AI開発の主戦場は、モデル比較から「作業環境」へ移った ──モデルは脳、harnessは職場 →

01速い​モデルは​諸刃 ──散らかった​職場では​速く​間違える

まず速度から。Claude Opus 4.8 fast mode は、モデルを小さいものに落とさず同じ賢さのまま出力を速くするプレビュー機能だ。^[1] Copilotでは Pro+ / Max / Business / Enterprise 向けに提供され、Business / Enterprise では管理者ポリシーでの有効化が要る。速さは反復量を増やす——同じ時間でより多く試せる。ここまでは良い話だ。

問題は、速さが方向を持たないことだ。職場が整っていれば「速く試して速く直す」になり、散らかっていれば「速く間違える」になる。だから速いモデルを入れるほど、その速さを受け止める職場の設計が効いてくる。職場を、AIから見た5つの要素——速度・分離・記憶・安全・文脈——で順に見ていく。

02分離と​記憶 ──机を​分け、​社内Wikiを​持たせる

速さの次は分離だ。複数のAIセッションを並列で動かすと、いちばん最初に起きるのが「作業が混ざる」事故になる。GitHub Desktop 3.6 が worktree をGit作業面に入れたのは象徴的で、作業ブランチを物理的に分けて、AIの机を1人1台にする発想だ。^[2] 1つの机に複数の仕事を広げさせない。

次が記憶。AIは毎回repoを総当たりで読むと、遅く・高コストで・見落とす。ここを担うのが2層ある。ひとつは AGENTS.md のようなrepo固有の指示ファイル——GitHubも repository custom instructions として正式に扱い、AIの作業文脈になる。^[3] もうひとつが codebase-memory-mcp のような記憶層で、repoをナレッジグラフにして総当たりでなく構造検索させる。READMEは「トークン約10分の1・ツール呼び出し約2.1分の1」をうたう（確認時点で約21,660★・MIT。数値はREADME上の主張で第三者再現は未確認）。^[4]

03安全 ──道具は​"入館ゲート"で​点検してから​渡す

速くて記憶もあるAIに、新しいスキルやMCPをどんどん渡したくなる。ここが今回いちばん強調したい点だ。スキルやMCPを増やすほど、便利さと一緒に"攻撃面"も増える。AIの手元に置く道具は、渡す前に点検したい。

これを担うのが SkillSpector（NVIDIA）のようなスキャナーだ。AIエージェントのスキルやMCPの脆弱性・悪意あるパターンを導入前に検出する。^[5] READMEは問題提起として「調べたスキルの26.1%に脆弱性、5.2%に悪意の可能性」という数字を挙げている（確認時点で約11,482★・Apache-2.0。この数値はREADMEの主張で、元研究・母集団はCAG未検証）。^[5] 数字の精度はさておき、「スキルは無条件に安全ではない」という前提に立たせてくれる。

安全は1つの道具で完結しない。Copilotのコードレビューが「深さ（review depth）」を設定でき、重要変更を深く読むようになったのも、^[6] MCPの権限を最小に絞るのも、同じ「職場の安全設備」だ。スキャナーは入館ゲート、レビュー深度は重要書類のダブルチェック、権限の絞り込みは鍵の管理——どれか一つでなく、束で効く。

関連記事 ｜ "鍵の管理"をもっと詳しくMCPは便利な拡張機能ではなく、権限レイヤーだ →

04文脈 ──UI・ブランドも​職場に​持ち込む

最後の要素が文脈、とくにデザインだ。AIにUIを作らせると、毎回「それっぽいけど自社らしくない」画面が出てくる。原因は、AIに渡しているのが「雰囲気」だけで、判断の根拠（design tokensと理由）が無いからだ。

ここを埋めようとするのが DESIGN.md（google-labs-code）という仕様で、ビジュアルアイデンティティやデザインシステムを、コーディングエージェントへtokenと根拠（rationale）として渡す。^[7] 確認時点で約23,268★・Apache-2.0。色やフォントの値だけでなく「なぜそうするか」を持たせることで、UI生成の当たり外れを減らそうという発想だ。

ただし注意も要る。DESIGN.mdはブランド文脈の入口であって、完成品質の保証ではない。実務では既存コンポーネント、実画面のスクリーンショット検証、Playwrightでの見た目チェックも要る。それでも「UIもAIの職場に持ち込む対象だ」という視点は効く。

05CAGの​AI職場パッケージ ──速度・分離・記憶・安全・​文脈の​5階層

ここからは現場の一次情報だ。私たちは受託開発でCodexやClaude Codeを毎日使うが、案件の品質を決めているのは「どのモデルか」より、どのrepoでも同じ"職場"を最初に組むことだと感じている。AIから見た職場を、次の5階層で標準化している。

階層	職場のたとえ	道具・標準化していること
速度	社員の脚力	fast modeや低遅延モデルを、タスクの重さで使い分ける
分離	机を分ける	worktree / branch / PR / preview で並行作業を混ぜない
記憶	社内Wiki・地図	AGENTS.md・docs/TASKS・記憶層で構造検索に寄せる
安全	入館ゲート・鍵	スキャン・MCP権限の最小化・削除/デプロイの承認ゲート
文脈	ブランドガイド	design token＋根拠・実画面のスクショ/Playwright検証

※ 道具名は一例。重要なのは「5階層を最初に組む」こと自体で、特定の製品に依存しない（モデルが新しくなっても作り直さなくてよい）。

この5階層はどれも特定のモデルに縛られない。だから速いモデルが来たら、整った職場で旧モデルと並べて走らせ、自分たちの作法を守れるかを確かめてから乗り換える。速い社員を雇う前に、職場が整っているか。これがCAGの順番だ。

06とは​いえ ──「職場さえ​あれば」も​「速ければ」も​誇張

反対側も正直に書く。「速いモデルは要らない」も「職場を整えれば全部解決」も、どちらも言い過ぎだ。差がつく軸が増えただけで、答えは足し算ではなく掛け算になる。

• 速いモデルは重要。反復量を増やすのは速さだ。設計・抽象化・セキュリティ判断・未知のバグ調査では、強く速いモデルがはっきり効く。
• でも速さは方向を持たない。職場設計が弱いと、速いモデルは高速に間違える。速さは、整った職場で初めて成果になる。
• worktreeは外部状態を分離しない。机は分けられても、DB・外部API・Vercel/Supabase・本番データは共有されたまま。ここは別の注意が要る。
• 記憶は古くなる。古いindexや誤ったグラフはAIを自信たっぷりに誤誘導する。更新・再index・出典確認をセットにする。
• スキャナーは最後の保証ではない。導入前スキャンに加えて、サンドボックス・人間レビュー・権限最小化・秘密値管理が要る。
• DESIGN.mdは入口。ブランド文脈は渡せても、完成品質は実画面の検証で確かめる。

だから結論はシンプルだ。速いモデル × 速く安全に働ける職場。どちらかがゼロなら成果もゼロに近づく。これからのAI開発者は、最強・最速モデルを当てる人ではなく、速いAIが安全に働ける職場を設計する人になる。モデルを雇う時代から、AIの職場を設計する時代へ。次の差分は、社員の銘柄ではなく職場のほうにある。

AI開発の見方	速いモデルだけ	速いモデル × 安全に働ける職場
速度	速く回す＝正義	速さを受け止める職場とセット
並行作業	ブランチが混ざる	worktreeで机を分ける
repo理解	毎回総当たり	AGENTS.md＋記憶層で構造検索
道具の追加	便利だから即導入	スキャン＋最小権限で点検
UI生成	雰囲気で出す	token＋根拠＋実画面検証
新モデル対応	来るたび振り回される	同じ職場で差分検証して乗り換え

※ 上表は「見方」の対比であり、モデル速度を軽視するものではない。差がつくのは「速いモデル ＋ 安全に働ける職場」の掛け算。外部ツールの数値・スター数は公式/GitHub上の主張でCAG非検証。