ターミナルが怖くて、結局チャットにコピペしていた
ずっと気になっていたことがありました。YouTubeで「Claude Code」という単語を見ない日がないのに、私は非エンジニアだからなるべくCodeを使わずにうまいことできないか、と目を逸らし続けていたんです。でも複数の事業を一人で回している以上、いつかは向き合わなきゃいけない。そう思って、腹をくくって勉強してみることにしました。
実は前にも一度触ったことがあります。そのときは、Claudeに「こういうコマンドを打ってください」と指示を書いてもらい、それを自分でターミナルにコピペし、出てきた結果をスクショして送り返す、という運用をしていました。クッソ面倒くさいけどプログラミングができないからだと思ってました。これで「使っている」つもりだったんです。今思えば、伝言ゲームをしていただけでした。
コワークとコードって、結局何が違うの
まず引っかかったのが、コワークとコードの違いです。同じClaudeなのに何が違うのか。聞いてみると、エンジンは同じでも、コワークは自動で裏側が動く仕組みで、細かな役割を自分で名前付けして配置することはできないと分かりました。一方コードは、自分で細かな役割を定義して置ける。YouTube動画で紹介されてるのはほどんどがコード。
コワークの方はなんとなくうまいことやってくれるのに対し、コードの方はこちらが細かく設定できる。なので精度を上げていく仕組みがきちんと作れればコードの方が思い通りになりそうだという解釈をしました。
「一つのプロジェクトを作ってそれぞれの役割を配置」という自分のイメージは、実はコワークではなくコードの方の話だったわけです。ここで一つ誤解が解けました。
インスタンスとコンテキストが分からなすぎた
YouTubeで紹介されていた「Gauntlet Loop（ガントレット・ループ）」について学びました。
ガントレットループは、AI投資家のMatt Shumer（元HyperWrite CEO）が名付けた、Claude Codeなど自律エージェント向けのマルチエージェント反復手法。Claude Opus 5とClaude Codeで、外部アセットを一切使わずCall of Dutyに近いクオリティのFPSゲームをThree.jsで自動生成したことで一気に話題になりました。 Claudeだけでゲームが作れちゃう時代なんですね…
核心のアイデア
1つのエージェントに「作らせて→自分で採点させて→終わり」とさせないことが肝。自己採点は必ず甘くなるので、役割を厳密に分離します。
- リード（オーケストレーター）エージェント — 全体の指揮者。ゴールを小さなパーツに分解する。実装は一切しない
- ビルダー（実装）エージェント — 各パーツを専門に担当し実際に作る
- クリティック（批評家）エージェント — ビルダーとは別インスタンス・別コンテキストで、実際の成果物だけを見て評価する。ビルダーがどれだけ頑張ったかの経緯は一切知らされない
- クリティックは実際の出力を「具体的な参照基準」とブラインドA/B比較する。参照基準は、ゲームなら市販の高品質タイトルのスクリーンショット、サイトなら競合の一流サイトなど、外部の実在物
- 基準に負けていれば、どこが劣っているかを明示してビルダーに差し戻し、ビルダーが改善→再度クリティックが判定、を繰り返す
失敗しやすいポイントは主に3つ：①基準が曖昧だとクリティックが適当に承認してしまう、②ビルダー自身に評価させると評価が甘くなる、③クリティックが優しすぎると機能しない点です。
なぜ効くのか
- 「もっと良くして」という抽象的なフィードバックは弱い。モデル自身が”良い”の定義を発明しなければならなくなるため。外部の具体的な比較対象を与えることで、判定基準がブレなくなる
- 参照基準は完全に到達可能である必要はなく、むしろ役割は「早すぎる完成宣言を防ぐこと」
- ゲームに限らずマーケティングサイトやホラー小説の執筆など、ゲーム以外の制作物にも応用できることをShumer自身が実演している
実際の使い方
- Claude CodeやCodex向けに「/gauntlet-loop」のようなスラッシュコマンドとして動くOSS版skillが複数公開されている（例：duolahypercho/gauntlet-loop、NicholasSpisak/gauntlet-loop）
- “You are the brake.”（止めるのは人間の役目）という注意書きがある通り、ループは自動では終わらない設計。人間がいつ打ち切るか判断する必要がある
賛否（確信度：中、X上の反応ベース）
面白い成果物を作れると評価する声がある一方、「ゴールに向かってループさせるという発想自体はShumerの発明ではない」「出力が使い回しに見える／信頼性に欠ける」という批判もある
私の事業文脈だと、コンテンツパイプライン（SEO記事のseo-3-1-draft-writer→seo-4-2-eeat-checker等、既にビルダー/クリティック分離の発想は近い設計になっています）に、この「外部の具体的な参照基準とのブラインド比較」という要素を追加すると精度が上がる可能性はあります。ただしループを無限に回す設計は、コスト管理上リスクがあるので要注意。
Gauntlet Loopという、ビルダーとクリティックを分けて品質を上げていく手法を教えてもらったとき、「別インスタンス」「フレッシュなコンテキスト」という言葉が出てきて、正直まったく意味が分かりませんでした。
聞いてみると、インスタンスは「起動している1人のClaude」、コンテキストは「そのClaudeが今見えている情報の範囲」とのこと。別のインスタンスで動かすということは、実装した本人の言い訳や試行錯誤を一切知らない、まっさらな目で評価させるということ。これでようやく、なぜわざわざ役割を分けるのかが腑に落ちました。ってか若い頃にプログラミングに挫折したのも今回もそうですが、英語ができたらもうちょっと覚えることが減るから理解しやすいのかもということ。英語だけは勉強しとけとあれほど言われたのに…
そもそも「フォルダ」が何のためにあるのか分からなかった
手順の説明で「プロジェクトフォルダに移動する」と言われても、そのフォルダに何を入れればいいのか見当がつきませんでした。聞いてみると、Claude Codeは「今いるフォルダの中身」しか見えない、つまりフォルダは作業範囲を区切る箱だと。空っぽから始めても大丈夫、Claudeが勝手にファイルを作ってくれる、と言われて、身構えていた自分が少し拍子抜けしました。
でもその後に調べていくと、パソコンのローカルフォルダを必ずしも使わなくてもクラウド上のみで完結できることもわかりました。
ターミナルとClaude Codeは別物だった
Terminalというアプリと、Claude Codeというエージェント。私はどっちの何で使うのかよくわかっていませんでした。
実際は、Terminalの中で「claude」と打つと、その中でClaude Codeが起動する、という関係だったんです。つまり、Terminalに指示する内容をClaudeCodeで作成してコピペして、Terminalの結果をスクショしてClaudeCodeに貼ってという作業を繰り返していた私、本当にアホですね…
Gitの用語が、想像以上に分からなかった
コミット、プッシュ、プル、クローン、ブランチ、プルリクエスト。聞いたことはあっても、意味を説明しろと言われたら一つも言えませんでした。特にプルリクエストは「最新情報をくださいというリクエスト」だと勝手に思い込んでいて、実際は真逆の「自分の変更を取り込んでください、というレビュー依頼」だったと分かったときは、素直に驚きました。
用語を一つずつ聞いていくと、Gitというソフトが変更履歴を記録し、GitHubというサービスがその記録をインターネット上に置く場所なんだという、当たり前の構造がようやく繋がりました。
ちょっとまだよく覚えてないので別記事で用語一覧作ります。
「パソコンの電源を入れなくてもできるのか」を諦めきれなかった
正直、一番聞きたかったのはここでした。GitHubがあればWeb上で全部完結できるんじゃないか、パソコンを立ち上げる必要すらないんじゃないか。ターミナルとかいらんのやないか。何度も同じような質問を形を変えてぶつけてしまいました。
結果、答えは「できる」でした。Claude Code on the webというクラウド版を使えば、ブラウザやスマホから指示するだけで、Anthropicのクラウド上の仮想マシンが作業してくれる。ページを閉じても作業は続く。ローカルにクローンする必要も、環境構築も要らない。ここに辿り着くまでに何往復もしましたが、諦めなくてよかったと思っています。
情報漏洩が怖くて、設定を細かく聞いた
一番怖いのは情報が漏れることです。リポジトリを作るときは必ずPrivateにすること、2段階認証を有効にすること、APIキーなどの機密情報は.gitignoreというファイルで除外すること。当たり前かもしれませんが、素人の私には一つひとつが初耳でした。デフォルト設定がパブリック（公開されてる）とか超怖いやん
トークン消費の話で、思い込みが二つ崩れた
最後にコストの話も聞きました。だってClaudeってトークン消費が激しくてすぐ利用制限になっちゃうから。
「長くなったら新しいチャットを立てた方がいい」は、話題が変わったときだけ正解で、同じ作業の続きならむしろ一つのセッションを保った方が安いことがある、という条件付きの答えでした。
「APIよりMCP連携の方がいい」に至っては、逆の可能性が高いと言われました。MCP接続の数が多いほど、ツール一覧を読み込む分のオーバーヘッドが増える。CLIツールがあるならそちらを優先すべき、と。YouTubeで言ってたことも、聞いてみると逆だったりするものです。
今日の着地
一日で全部を理解できたわけではありません。今も、コマンドを打つたびに「これで合っているのか」と半信半疑になると思います。でも、分からないことを分からないまま放置せず、一つずつ「それって結局どういうこと」と聞き直していけば、非エンジニアでも構造は繋がっていくんだと分かったのが、今日一番の収穫でした。
数十年分からなかったことが一日で腹落ちするわけがないので、これからも何度も同じところで引っかかりながら、少しずつ手放していければいいと思っています。
コメント