Claude Codeを作った本人が語った衝撃の一言
「もうプロンプトは書いていない」
Claude Codeの開発者であるBoris Cherny氏が語ったこの一言が、世界中の開発者の間で大きな話題になりました。
多くの人はAIを使うとき、まずプロンプトを書きます。
「このコードを書いてください」
「このバグを修正してください」
「この機能を追加してください」
そして結果を確認し、問題があれば再び指示を出します。
現在のAI活用のほとんどは、この繰り返しです。
しかしClaude Codeを生み出した本人は、まったく違う使い方をしています。
彼はAIに毎回指示を出していません。
代わりに行っているのは、
AIへ指示する方法そのものを自動化することです。
つまり、
「AIへの依頼」を作るのではなく、
「AIが自動で動く仕組み」を作っています。
Boris氏は自身の仕事について、
仕事とはループを書くこと
だと説明しています。
この発言だけを見ると意味が分からないかもしれません。
しかし詳しく調べると、AI活用の未来を示す非常に重要な考え方が隠れていました。
従来の開発者は、
コードを書く
↓
テストする
↓
修正する
↓
レビュー対応する
↓
プルリクエストを出す
という流れを毎日何度も繰り返していました。
一方でBoris氏は、
コードを書くAI
↓
テストするAI
↓
レビューするAI
↓
修正するAI
↓
プルリクエストを出すAI
を作り、その全体を自動で回しています。
つまり人間が作業をするのではなく、
作業する仕組みを設計しているのです。
ここが従来のAI活用と決定的に違うポイントです。
多くの人はAIを便利なチャットツールとして使っています。
分からないことを質問する。
文章を書いてもらう。
コードを書いてもらう。
確かにこれでも十分便利です。
しかしClaude Codeを開発した本人は、AIをチャットツールとして見ていません。
AIを作業者として見ています。
さらに言えば、
複数のAI作業者を管理するマネージャーとして使っています。
この考え方の違いによって、生産性には圧倒的な差が生まれます。
例えば一般的な開発者が1つのプルリクエストを作る場合、
実装
↓
動作確認
↓
コミット
↓
プッシュ
↓
レビュー対応
まで含めると数十分から数時間かかることもあります。
しかしBoris氏が公開したワークフローでは、
コミット
プッシュ
プルリクエスト作成
までを1つのコマンドで実行できます。
さらにコードレビューへの対応も自動化されています。
フィードバックの取得。
修正。
テスト。
再提出。
これらの一連の流れもループとして構築されています。
結果として、人間はコードを書く時間よりも、
ループを改善する時間の方が長くなります。
だからこそ彼は、
もうプロンプトは書いていない
と語ったのです。
実際、この考え方はClaude Codeだけの話ではありません。
2026年現在のAI業界全体が、
チャットAI
から
AIエージェント
へ移行しています。
単発の質問に答えるAIではなく、
複数のタスクを自律的に実行するAIへ進化しているのです。
そしてその最前線にいるのがClaude Codeです。
だから今、
Claude Codeを単なるコーディング支援ツールとして使っている人と、
自動化プラットフォームとして使っている人では、
生産性に大きな差が生まれ始めています。
この差は今後さらに広がるでしょう。
なぜならAI時代に価値を生むのは、
良いプロンプトを書く能力ではなく、
良いループを設計する能力だからです。
では実際にBoris Cherny氏はどのようなループを作り、どのようにClaude Codeを運用しているのでしょうか。
次章では、Claude Codeの生みの親であるBoris Cherny氏の正体と、なぜ彼の発言が世界中の開発者を驚かせたのかを詳しく解説します。
Boris Chernyとは誰なのか なぜ世界中の開発者が注目したのか
Claude Codeの使い方を調べていると、必ず名前が出てくる人物がいます。
それがBoris Cherny氏です。
AI業界では日々さまざまな発信が行われていますが、その中でも彼の発言が特別な注目を集めた理由があります。
それは単なる評論家やインフルエンサーではなく、Claude Codeそのものを開発した中心人物だからです。
スポーツカーの性能について語る人はたくさんいます。
しかし実際にその車を設計したエンジニアが運転方法を解説したらどうでしょうか。
説得力はまったく違います。
Claude Codeにおいて、Boris氏はまさにその立場にいる人物です。
だからこそ彼が公開した日常的な使い方に、世界中の開発者が注目しました。
多くの人が驚いたのは、彼がClaude Codeを使っていたからではありません。
むしろ逆です。
Claude Codeを作った本人が、一般ユーザーとはまったく違う使い方をしていたからです。
当時、多くの開発者はAIコーディング支援ツールを次のように使っていました。
エラーを修正してもらう。
関数を書いてもらう。
リファクタリングしてもらう。
テストコードを生成してもらう。
ドキュメントを書いてもらう。
これは現在でも一般的な使い方です。
実際に非常に便利ですし、生産性向上にもつながります。
しかしBoris氏はそうした使い方を中心にしていませんでした。
彼が行っていたのは、
作業の自動化
です。
さらに言えば、
自動化の自動化
です。
ここが極めて重要なポイントです。
例えば普通の開発者なら、
「このコードを修正してください」
というプロンプトを書きます。
修正されたコードを確認します。
問題があれば再度修正を依頼します。
これを何度も繰り返します。
しかしBoris氏は、
修正するループ
確認するループ
レビューするループ
提出するループ
を作ります。
つまり人間がAIを操作するのではなく、AIが自動で仕事を進める環境を構築しているのです。
この考え方が公開されたとき、多くの開発者が衝撃を受けました。
なぜなら彼らはClaude Codeをツールとして見ていたからです。
一方でBoris氏はClaude Codeを労働力として見ていました。
これは発想そのものが違います。
電卓として使うのか。
社員として使うのか。
そのくらい大きな違いがあります。
実際に彼が公開した運用例を見ると、その思想がよく分かります。
コミットからプルリクエスト作成までを自動化するループ。
コードレビュー対応を継続的に監視するループ。
Slack上のフィードバックを取得して反映するループ。
ブラウザで動作確認を行う検証ループ。
これらは単なる便利機能ではありません。
開発チームの業務フローそのものです。
つまり彼はClaude Codeを使っているのではなく、
開発組織そのものを再設計している
とも言えます。
そしてこの考え方は偶然生まれたものではありません。
AI業界全体が向かっている方向そのものです。
以前のAIは質問に答える存在でした。
検索エンジンの延長線上にありました。
しかし現在のAIは違います。
調査する。
判断する。
実装する。
修正する。
確認する。
報告する。
こうした複数工程をまとめて実行する存在へ進化しています。
いわゆるAIエージェントです。
Boris氏が公開した使い方は、その最前線に位置しています。
だから開発者コミュニティは騒然となりました。
単なる便利な活用事例ではなく、
数年後の標準的な働き方が見えた
からです。
特に象徴的だったのが、
仕事とはループを書くこと
という考え方でした。
従来のソフトウェア開発では、
コードを書くことが仕事でした。
AI時代初期には、
プロンプトを書くことが仕事になりました。
しかし今はさらに進化しています。
ループを書く。
ワークフローを書く。
AIチームを設計する。
これが新しい仕事になりつつあります。
つまり開発者の役割そのものが変わっているのです。
コードを書く人から、
AIに仕事をさせる仕組みを作る人へ。
これがBoris氏の発信が大きな反響を呼んだ理由です。
そして次章では、
「もうプロンプトは書かない」
という発言の本当の意味についてさらに深く掘り下げます。
なぜプロンプトエンジニアリングが限界を迎えつつあるのか。
なぜループ設計が次の時代のスキルになるのか。
Claude Codeの思想を理解するうえで最も重要なテーマを解説していきます。
もうプロンプトは書かない 本当の意味とは
「もうプロンプトは書いていない」
この言葉だけを見ると誤解しやすいかもしれません。
AIを使わなくなったという意味ではありません。
むしろ逆です。
誰よりもAIを使い込んだ結果、プロンプトを書く時間がほとんどなくなったという意味です。
これは現在のAI活用を理解するうえで非常に重要な考え方です。
多くの人はAIを使うとき、
質問を考える
↓
プロンプトを書く
↓
回答を受け取る
↓
修正指示を出す
↓
再実行する
という流れで作業しています。
例えばプログラム開発の場合、
ログイン機能を作ってください
テストコードも追加してください
エラーが出たので修正してください
レスポンス速度を改善してください
このような会話を何度も繰り返します。
一見すると効率的に見えます。
実際、従来よりはるかに速く開発できます。
しかしBoris氏はここに大きな無駄を見つけました。
なぜ毎回同じ指示を出しているのか。
なぜ毎回同じ確認をしているのか。
なぜ毎回同じレビュー対応をしているのか。
なぜ毎回同じ手順でプルリクエストを作っているのか。
もし毎日繰り返しているなら、
その作業自体を自動化できるはずです。
ここからループという考え方が生まれます。
ループとは、
繰り返し発生する仕事を一連の流れとして固定化したもの
です。
例えば一般的な開発者の一日を考えてみましょう。
コードを書く。
テストを実行する。
Lintを実行する。
コミットする。
プッシュする。
プルリクエストを作る。
レビューコメントを確認する。
修正する。
再提出する。
これらは毎日何度も発生します。
つまり定型業務です。
定型業務である以上、自動化できます。
Boris氏はこの事実に徹底的に向き合いました。
結果として生まれたのが、
slash command
という運用スタイルです。
例えばコミット作業を考えてみましょう。
普通なら次の流れになります。
変更内容を確認する。
git addを実行する。
コミットメッセージを考える。
コミットする。
プッシュする。
プルリクエストを作成する。
レビュアーを設定する。
これだけで数分かかります。
しかし毎日何十回も繰り返しているならどうでしょうか。
そこでBoris氏は、
commit-push-pr
というループを作りました。
一つのコマンドを実行するだけで、
変更内容の確認。
コミット文の作成。
コミット。
プッシュ。
プルリクエスト作成。
までを自動で実行します。
ここで重要なのは、
AIに作業を依頼しているのではない
ということです。
AIに仕事の流れそのものを任せています。
つまりプロンプトを書くのではなく、
ワークフローを書く
という状態です。
これこそが、
仕事はループを書くこと
という発言の本質です。
実際、この考え方はプログラミングだけに限りません。
マーケティングでも同じです。
コンテンツ企画。
競合調査。
キーワード分析。
記事構成作成。
本文執筆。
校正。
投稿。
効果測定。
多くの人はこれを個別作業として行っています。
しかし本質的には繰り返し作業です。
つまりループ化できます。
営業も同じです。
顧客調査。
提案資料作成。
メール作成。
フォローアップ。
議事録作成。
次回提案。
これもループです。
経理も人事もカスタマーサポートも同じです。
AI時代に価値が生まれるのは、
仕事を上手にこなす人
ではありません。
仕事をループ化できる人です。
なぜなら一度ループを作れば、
その後は何百回でも再利用できるからです。
これは人間の労働時間を増やす考え方ではありません。
人間の労働そのものを仕組みに変換する考え方です。
そして現在のAI業界では、この考え方が急速に広がっています。
以前は、
良いプロンプトを書ける人
が評価されていました。
しかし今は違います。
良いワークフローを設計できる人。
良いエージェントを構築できる人。
良いループを作れる人。
こうした人材の価値が急速に高まっています。
実際にBoris氏自身も、
プロンプトを書く時間より、
ループを改善する時間の方が長い
と語っています。
つまり彼にとってAIとの会話は目的ではありません。
目的は仕組み作りです。
この考え方を理解すると、
Claude Codeが単なるAIコーディングツールではないことが分かります。
Claude Codeの本質は、
AIエージェントを動かすための実行基盤
なのです。
だからこそ、単に質問して終わる使い方では本来の価値を引き出せません。
本当に重要なのは、
どんなループを作るのか
です。
そしてBoris氏は、そのループを具体的に公開しています。
次章では、実際に彼が日常的に使っているslash commandを詳しく解説します。
なぜ一日に何十本ものプルリクエストを処理できるのか。
なぜAIにコードを書かせながら品質を維持できるのか。
その秘密が見えてきます。
Boris Chernyが実際に使っているループの全貌
ここまで読んで、
ループの重要性は分かった。
でも実際に何を自動化しているのか。
そう思った方も多いでしょう。
そこで次は、Boris Cherny氏が実際に公開している運用方法を詳しく見ていきます。
重要なのは、ここで紹介する内容は特別な研究プロジェクトではないということです。
日常的な開発業務そのものです。
つまり誰もが毎日行っている仕事です。
そしてだからこそ、大きな生産性向上につながっています。
まず理解しておきたいのは、
Boris氏はAIにコードを書かせること自体にはそれほど価値を置いていない
という点です。
本当に価値を置いているのは、
コードを書く前後に発生する大量の雑務
です。
現実の開発現場では、
コードを書く時間より、
確認する時間
修正する時間
レビューする時間
管理する時間
の方が長いケースも珍しくありません。
そこで彼は、その部分を徹底的にループ化しました。
commit push PRを一撃で終わらせるループ
多くの開発者は一日の中で何度も同じ作業を繰り返しています。
変更を保存する。
コミットする。
プッシュする。
プルリクエストを作る。
レビュアーを設定する。
これらは単純作業ですが、積み重なると大きな時間になります。
例えば1回あたり3分かかったとします。
1日に20回行えば60分です。
年間では数百時間になります。
Boris氏はここをループ化しました。
commit-push-pr
というコマンドを実行すると、
Claude Codeが変更内容を確認します。
適切なコミットメッセージを考えます。
Gitへコミットします。
リモートへプッシュします。
プルリクエストを作成します。
必要な情報を整理します。
つまり開発者は、
「終わったから提出する」
と判断するだけです。
提出作業そのものはAIが行います。
従来なら数分かかっていた作業が数秒になります。
しかし本当に重要なのは時間短縮ではありません。
認知負荷の削減です。
人間は作業を切り替えるたびに集中力を失います。
コーディングからGit操作へ。
Git操作からPR作成へ。
PR作成からレビュー依頼へ。
こうした切り替えが消えることで、本来集中すべき問題解決に時間を使えるようになります。
babysitという最強の雑務処理ループ
Boris氏が公開した中でも特に注目されたのが、
babysit
というループです。
名前だけ聞くと何をするのか分かりません。
しかし実際の役割は非常に強力です。
簡単に言うと、
AIにプロジェクト管理者をやらせる
ための仕組みです。
開発現場では常に状況が変化しています。
レビュー依頼が来る。
競合ブランチが更新される。
コンフリクトが発生する。
PRにコメントが付く。
CIが失敗する。
これらは放置すると開発速度を大きく下げます。
しかし逐一確認するのも面倒です。
そこでbabysitループが定期的に動作します。
レビュー状況を確認する。
rebaseが必要か調べる。
競合状態を確認する。
優先順位を整理する。
必要に応じて修正する。
つまり人間が監視していた部分をAIが代行しています。
これが24時間動き続けます。
人間が寝ている間もです。
仕事をしていない時間にも、プロジェクトは前進し続けます。
ここにAIエージェント時代の本質があります。
人間が働く時間だけ成果が出るのではありません。
ループが動いている限り成果が積み上がります。
Slackフィードバック対応も自動化する
さらに興味深いのが、
slack-feedback
という運用です。
通常の開発現場では、
フィードバックが届く。
確認する。
修正する。
再提出する。
という流れになります。
一つ一つは小さな作業です。
しかし件数が増えると大きな負担になります。
特に大規模プロジェクトでは毎日大量のレビューコメントが発生します。
Boris氏はここも自動化しました。
Slackのフィードバックを取得する。
内容を分析する。
修正内容を理解する。
必要な変更を実施する。
再テストする。
プルリクエストを更新する。
これらをループとして実行しています。
人間がやるのは、
最終的な判断だけです。
これによってレビューサイクルが劇的に高速化します。
AIが単なるアシスタントではなく、
チームメンバーとして動いている状態です。
ここで見えてくる本当の変化
多くの人はClaude Codeを使うとき、
コード生成ツール
として見ています。
しかしBoris氏の運用を見ると違います。
彼が構築しているのは、
コード生成システム
です。
さらに言えば、
AI開発組織
です。
コミット担当。
レビュー担当。
フィードバック担当。
進捗管理担当。
これらをすべてAIで構成しています。
つまりClaude Codeを一人の優秀なエンジニアとして使うのではなく、
小さな開発チームとして運用しているのです。
これが一般ユーザーとの決定的な差です。
そして、この運用を成立させるために絶対に欠かせない仕組みがあります。
それが次章で解説する
verify-app
です。
実はBoris氏は、
AIの出力を信用していません。
だからこそ品質を維持できています。
なぜ彼が「確認なしで完了を認めない」というルールを作ったのか。
その理由を次章で詳しく解説します。
verify-appがClaude Code運用の心臓部である理由
Claude Codeの活用事例を見ると、多くの人は自動化の部分に目を奪われます。
commit-push-pr。
babysit。
slack-feedback。
どれも非常に魅力的です。
しかし実際には、これら以上に重要な仕組みがあります。
それが
verify-app
です。
もしClaude Codeの思想を一言で表現するなら、
AIを信用しない仕組みを作る
と言っても過言ではありません。
これは一見矛盾しているように聞こえるかもしれません。
AIを活用しているのにAIを信用しない。
しかし実はこれこそが、Boris Cherny氏が生産性と品質を両立できている最大の理由です。
AIは優秀だが完璧ではない
まず前提として理解しておきたいことがあります。
現在のAIは驚くほど優秀です。
コードを書けます。
バグを修正できます。
設計もできます。
テストコードも作れます。
ドキュメントも作成できます。
しかし、
正しいコードを書ける
ことと
動くコードを書ける
ことは別問題です。
実際の開発現場では、
見た目は完璧なのに動かないコード
が頻繁に発生します。
コンパイルは通る。
テストも通る。
しかし実際の画面操作でエラーが出る。
想定外の挙動が発生する。
ユーザー体験が壊れる。
こうした問題は珍しくありません。
そしてAIは自信満々に、
修正が完了しました
すべて正常に動作しています
と報告することがあります。
しかし実際には確認していないケースもあります。
これはClaudeだけではありません。
現在存在するすべてのAIに共通する特徴です。
だからこそ、
AIの報告を信用してはいけない
という考え方が重要になります。
Boris氏が作った絶対ルール
Boris氏は非常にシンプルなルールを設けています。
確認していないタスクは完了ではない
というルールです。
どれだけAIが自信を持っていても関係ありません。
どれだけコードが綺麗でも関係ありません。
どれだけテストが成功していても関係ありません。
実際に動作確認が完了するまで、
その仕事は終わっていません。
これは従来のソフトウェア開発でも重要な考え方でした。
しかしAI時代になるとさらに重要性が高まります。
なぜならAIは人間より速く間違えるからです。
一秒で数百行のコードを書けます。
つまり一秒で数百行のバグも作れます。
だから速度だけを追求すると危険です。
そこでverify-appが登場します。
verify-appは何をしているのか
verify-appは簡単に言うと、
AI専用の品質保証担当者
です。
Claude Codeがコードを書いた後、
別の検証ループが起動します。
アプリケーションを起動する。
ブラウザを開く。
画面を操作する。
ボタンをクリックする。
フォームを入力する。
期待通りに動くか確認する。
エラーが出ていないか確認する。
UIが崩れていないか確認する。
これらを自動で実施します。
ここで重要なのは、
コードを見て判断していない
という点です。
実際に使って確認しています。
人間のQA担当者が行う作業をAIが代行しているのです。
なぜ開発者はverify-appに衝撃を受けたのか
多くの開発者が驚いた理由は、
コード生成より検証の方が重要だった
という事実です。
従来のAI活用では、
どうやって高品質なコードを書かせるか
ばかりが議論されていました。
プロンプトを工夫する。
コンテキストを増やす。
ルールを追加する。
しかしBoris氏は別方向から考えました。
完璧なコードを書かせるのは難しい。
なら検証を自動化しよう。
この発想の転換です。
実際の開発現場でも同じです。
優秀なエンジニアほど、
ミスをしない人
ではありません。
ミスを早く発見できる人
です。
verify-appはまさにその考え方を体現しています。
AIエージェント時代の品質管理
ここで非常に重要なポイントがあります。
今後AIエージェントが普及すると、
一人のAIではなく複数のAIが同時に働くようになります。
実装担当AI。
レビュー担当AI。
テスト担当AI。
ドキュメント担当AI。
調査担当AI。
これらが並列で動きます。
すると開発速度は劇的に向上します。
しかし同時に、
間違いも高速化します。
品質管理が追いつかなければ大事故になります。
だからこそ、
実装AIより検証AIの方が重要
という考え方が生まれます。
実際、現在の先進的なAI開発チームでは、
生成より検証に重点を置くケースが増えています。
コードを書くことは簡単になりました。
難しいのは、
本当に正しく動くか確認することです。
verify-appから学ぶべき本質
多くの人はClaude Codeの活用事例を見ると、
どうやってコード生成を自動化するか
に注目します。
しかし本当に学ぶべきなのはそこではありません。
重要なのは、
AIの成果物を検証する仕組みを作ること
です。
実はこれは開発以外にも応用できます。
SEO記事ならどうでしょうか。
AIが記事を書く。
別のAIが事実確認する。
別のAIがSEO観点でチェックする。
別のAIが読者目線でレビューする。
動画制作でも同じです。
AIが台本を書く。
AIが構成を評価する。
AIが視聴維持率を予測する。
AIが改善点を提示する。
つまりAIを増やすだけでは不十分です。
検証ループまで設計して初めて本当の自動化になります。
そしてこの思想こそが、次に登場するDynamic Workflowsの核心でもあります。
Claude Codeの未来は単なるコーディング支援ではありません。
AI同士が役割分担しながら仕事を進める世界です。
次章ではAnthropicが発表したDynamic Workflowsについて解説します。
なぜ業界が「AIエージェント時代の始まり」と騒いだのか。
なぜBoris氏の発言と完全につながるのか。
その全貌を詳しく見ていきます。
Dynamic Workflowsが示すAI時代の新しい働き方
Boris Cherny氏が
仕事とはループを書くこと
と語ったとき、多くの人は未来の話だと思っていました。
しかし実際には違いました。
その未来はすでに始まっています。
そして、その象徴とも言えるのがAnthropicが発表した
Dynamic Workflows
です。
この機能が注目された理由は単純です。
Claudeが単なるチャットAIではなく、
自律的に働くシステムへ進化し始めたからです。
これまでのAIは基本的に受け身でした。
人間が質問する。
AIが回答する。
人間が次の指示を出す。
AIが再び回答する。
この繰り返しです。
どれだけ賢くても、
人間が指示を出し続ける必要がありました。
しかしDynamic Workflowsでは状況が変わります。
AI自身が考えます。
AI自身が計画します。
AI自身が役割分担します。
AI自身が作業を実行します。
AI自身が結果を評価します。
つまり、
指示待ちのAI
から
自律的に動くAI
へ進化しているのです。
なぜDynamic Workflowsが革命なのか
従来のAI活用には大きな問題がありました。
タスクが大きくなるほど、人間の管理コストも増えることです。
例えば大規模システムの改善を考えてみましょう。
まずコードベースを調査する。
問題箇所を特定する。
修正方針を決める。
影響範囲を分析する。
コードを書く。
テストする。
レビューする。
修正する。
この流れを人間が管理する必要がありました。
仮にAIがコードを書いてくれても、
全体を監督するのは人間です。
ここがボトルネックでした。
しかしDynamic Workflowsでは違います。
Claude自身が、
まず何を調査するべきか
どの作業を並列化できるか
どのサブエージェントに任せるか
どの順番で進めるか
を判断します。
つまり人間は、
目的
だけを与えればよくなります。
途中の管理業務が激減するのです。
Boris氏の思想と完全につながる
ここで思い出してほしいのが、
仕事とはループを書くこと
という考え方です。
実はDynamic Workflowsは、この思想をさらに一歩進めたものです。
従来は人間がループを書いていました。
commit-push-prを作る。
babysitを作る。
verify-appを作る。
slack-feedbackを作る。
すべて人間が設計していました。
しかしDynamic Workflowsでは、
Claude自身がループを構築できる
ようになります。
つまり、
人間がAIに仕事を教える
世界から、
AIが自分で仕事の進め方を考える
世界へ移行しているのです。
これは非常に大きな変化です。
サブエージェントがチームになる時代
Dynamic Workflowsの本質は、
AIが複数のAIを管理すること
にあります。
従来は一人の優秀なAIを使っていました。
しかしこれからは違います。
調査担当AI。
設計担当AI。
実装担当AI。
テスト担当AI。
レビュー担当AI。
品質保証担当AI。
これらが同時に動きます。
しかも並列です。
人間のチーム開発と非常によく似ています。
例えば大規模なリファクタリングを行う場合、
一人で作業すると数週間かかります。
しかし10人のチームなら作業を分担できます。
Dynamic WorkflowsはこれをAIで実現しています。
だから生産性が飛躍的に向上するのです。
実際に起きている驚異的な事例
この考え方が単なる理論ではないことは、すでに複数の事例で証明されています。
大規模コードベースの移植。
レガシーシステムの解析。
デッドコードの発見。
品質改善。
技術的負債の削減。
従来なら数か月単位で進めていたプロジェクトが、
数日から数週間で完了するケースも出始めています。
重要なのは、
AIが賢くなったから
ではありません。
AI同士が協力できるようになったから
です。
ここが最大のポイントです。
これから価値が上がる人材
Dynamic Workflowsが普及すると、
エンジニアの価値も変わります。
以前はコードを書く量が重要でした。
AI時代初期はプロンプトを書く能力が重要でした。
しかしこれからは違います。
求められるのは、
仕事を分解できる人
です。
仕事を構造化できる人。
業務フローを設計できる人。
検証プロセスを考えられる人。
AIチームをマネジメントできる人。
こうした人材の価値が急速に高まります。
なぜならAIは作業を代替できますが、
目的設定や仕組み設計は依然として人間の重要な役割だからです。
Claude CodeはチャットAIではない
ここまで読んで分かる通り、
Claude Codeを単なるチャットAIとして見ると本質を見誤ります。
確かにコードも書けます。
質問にも答えます。
しかし本当の価値はそこではありません。
Claude Codeは、
AIチームを動かすための実行環境
です。
そしてDynamic Workflowsは、
その思想をさらに発展させた仕組みです。
だから今後、
Claude Codeを検索代わりに使う人と、
ワークフロー基盤として使う人では、
生産性の差がますます広がっていくでしょう。
では実際に私たちは何から始めればよいのでしょうか。
次章では、Boris Cherny氏の運用を参考にしながら、一般ユーザーでも今日から実践できるClaude Code活用法を具体的に解説します。
難しい知識は必要ありません。
まずは小さなループを一つ作ることから始めれば十分です。
今日から実践できる Claude Code活用法 本人の使い方を自分の仕事へ応用する方法
ここまで読んで、
Boris Cherny氏の考え方は分かった。
でも自分はAnthropicのエンジニアではない。
そこまで大規模な開発もしていない。
そう感じた方もいるでしょう。
実はそれで問題ありません。
なぜなら、今回の話で本当に重要なのはClaude Codeの高度な機能ではなく、
仕事の見方そのもの
だからです。
Boris氏が特別なのは、優秀なエンジニアだからではありません。
自分の仕事をループとして捉えているからです。
そしてこの考え方は、開発者以外にも応用できます。
むしろ今後は、あらゆる職種で必要になる考え方です。
最初にやるべきことはプロンプト改善ではない
Claude Codeを使い始めると、多くの人がプロンプト改善に時間を使います。
もっと上手な指示を書こう。
もっと長いコンテキストを渡そう。
もっと詳細な条件を書こう。
もちろん重要です。
しかしBoris氏の思想から学ぶなら、
最初に考えるべきは別です。
毎週繰り返している仕事は何か
です。
例えば開発者なら、
コードレビュー。
テスト実行。
ドキュメント更新。
リリース準備。
PR作成。
エラーログ調査。
こうした業務があります。
マーケターなら、
競合分析。
キーワード調査。
記事構成作成。
SNS投稿作成。
レポート作成。
効果測定。
コンテンツ改善。
こうした業務があります。
重要なのは、
毎回やっている仕事
を見つけることです。
なぜならループ化できるのは、繰り返し発生する仕事だからです。
まずは週3回以上やる作業を探す
Boris氏の運用を見ると分かりますが、
彼は毎日発生する仕事から自動化しています。
これは非常に合理的です。
月に一回しかやらない作業を自動化しても効果は小さいからです。
おすすめなのは、
週に3回以上やる仕事
を洗い出すことです。
例えばSEO記事を書く場合なら、
競合記事を調査する。
検索意図を分析する。
見出しを作る。
不足トピックを探す。
本文を書く。
校正する。
タイトルを改善する。
メタディスクリプションを作る。
これらは毎回発生します。
つまりループ化候補です。
Claudeに仕事の流れを覚えさせる
多くの人は毎回ゼロから指示を出しています。
しかし実際には、仕事の進め方はほぼ同じです。
SEO記事を書く場合も、
競合調査。
検索意図分析。
見出し設計。
本文執筆。
内部リンク提案。
まとめ作成。
という流れは変わりません。
ならば、その流れ自体をClaudeへ渡します。
すると毎回説明する必要がなくなります。
これがループの第一歩です。
Boris氏が行っていることも本質的には同じです。
仕事の進め方を固定化し、再利用できる形にしています。
AIに仕事を任せる前に検証ループを作る
そして最も重要なのがここです。
多くの人は、
AIに任せる
ところで止まります。
しかしBoris氏は違います。
必ず検証を入れます。
これがverify-appの思想です。
例えばSEO記事なら、
事実確認。
重複表現チェック。
検索意図との一致確認。
見出し構造の確認。
読みやすさ確認。
E-E-A-T観点の確認。
こうしたレビュー工程を追加します。
SNS投稿でも同じです。
炎上リスク確認。
誤情報確認。
ターゲットとの一致確認。
CTA確認。
こうした工程を設けます。
つまり、
生成ループ
だけではなく、
検証ループ
も作るのです。
ここで成果物の品質が大きく変わります。
Claude Codeを使う人と使いこなす人の差
現在、多くの人はClaude Codeを
高性能チャット
として使っています。
質問する。
回答をもらう。
終わり。
これは悪いことではありません。
しかしBoris氏が示している未来は違います。
仕事を分解する。
ループ化する。
検証する。
改善する。
再利用する。
この流れです。
つまりClaude Codeを使う人と、
Claude Codeを基盤として仕事を設計する人
では成果が大きく変わります。
数か月後にはその差が明確になるでしょう。
AI時代に最も価値が上がるスキル
かつて重要だったのは、
タイピング速度でした。
その後は、
プログラミング能力でした。
そしてAI時代初期には、
プロンプトエンジニアリング
が注目されました。
しかし今、最前線ではさらに次の段階へ進んでいます。
それが
ワークフロー設計
です。
ループ設計。
エージェント設計。
検証設計。
品質管理設計。
これらが新しい競争力になります。
実際にBoris氏自身も、
コードを書く時間より、
ループを改善する時間の方が長い
と語っています。
つまり価値の源泉が変わったのです。
コードを書くことではなく、
コードを書く仕組みを作ること。
プロンプトを書くことではなく、
AIが動く環境を作ること。
これがClaude Codeの本質です。
そして今後数年間で、この考え方はソフトウェア開発だけでなく、
マーケティング
SEO
営業
経理
採用
カスタマーサポート
コンテンツ制作
動画編集
デザイン
などあらゆる業界へ広がっていくでしょう。
では最後に、
Claude Codeを作った本人の使い方から見えてくる未来についてまとめます。
なぜ彼の発言が世界中の開発者に衝撃を与えたのか。
そして私たちはこれから何を学ぶべきなのかを総括します。
まとめ もうプロンプトを書く時代からループを設計する時代へ
Claude Codeを作った本人であるBoris Cherny氏の使い方が大きな話題になった理由は、便利なテクニックを公開したからではありません。
AIとの向き合い方そのものが変わっていたからです。
多くの人は今でもAIをチャットツールとして使っています。
質問する。
回答をもらう。
修正する。
再度質問する。
これは現在最も一般的な使い方です。
そして間違った使い方でもありません。
実際に大きな生産性向上が得られます。
しかしBoris氏が示した世界は、そのさらに先にあります。
彼はAIに仕事を依頼していません。
AIが仕事を進める仕組みを作っています。
だからこそ、
もうプロンプトは書いていない
という発言につながりました。
この言葉の本当の意味は、
AIを使わなくなった
ではありません。
AIを使い込みすぎた結果、
毎回指示を出す必要がなくなった
ということです。
実際に彼が公開した運用を見ると、その思想がよく分かります。
commit-push-prによる提出業務の自動化。
babysitによるプロジェクト管理の自動化。
slack-feedbackによるレビュー対応の自動化。
verify-appによる品質保証の自動化。
そして複数のサブエージェントによる役割分担。
これらは単なる便利機能ではありません。
人間が行っていた仕事をループとして定義し、AIへ移管しているのです。
ここにClaude Codeの本質があります。
多くの人はClaude Codeを、
コードを書いてくれるAI
だと思っています。
しかし実際には違います。
Claude Codeは、
AIチームを動かすための実行基盤
です。
そしてAnthropicが発表したDynamic Workflowsは、その方向性をさらに加速させています。
AIが計画する。
AIが分担する。
AIが実装する。
AIが検証する。
AIが改善する。
こうした流れが当たり前になりつつあります。
つまり私たちは今、
チャットAI時代
から
AIエージェント時代
への転換点に立っています。
この変化によって価値のあるスキルも変わります。
過去はコードを書く能力が重要でした。
その後はプロンプトを書く能力が注目されました。
しかしこれから重要になるのは、
仕事を分解する能力
ワークフローを設計する能力
ループを構築する能力
検証プロセスを作る能力
AIチームをマネジメントする能力
です。
つまり人間が作業者である必要はなくなります。
代わりに、
仕組みを作る人
の価値が高まります。
これは開発者だけの話ではありません。
SEO担当者も同じです。
マーケターも同じです。
営業も同じです。
動画編集者も同じです。
SNS運用者も同じです。
繰り返し発生する仕事がある限り、そこにはループ化の余地があります。
そしてループ化できる仕事は、いずれAIエージェントが担当するようになります。
だから今から学ぶべきことは、
より長いプロンプトを書くこと
ではありません。
より高度な仕事の進め方を設計することです。
Boris Cherny氏の発言が世界中の開発者に衝撃を与えたのは、まさにこの点でした。
彼は未来を予測していたのではありません。
すでに未来の働き方を実践していたのです。
Claude CodeをチャットAIとして使うだけでも十分価値があります。
しかし本当の可能性はその先にあります。
もしあなたがClaude Codeを使っているなら、一度自分の仕事を見直してみてください。
毎日繰り返している作業は何でしょうか。
毎週同じように行っている業務は何でしょうか。
その中にループ化できるものはないでしょうか。
そこに気づいた瞬間から、Claude Codeは単なるAIツールではなくなります。
仕事を自動化する基盤になり、
やがてあなた専用のAIチームへと進化していくはずです。
そして数年後に振り返ったとき、
プロンプトを書いていた時代があった
と感じる日が来るかもしれません。
Claude Codeを作った本人が教えてくれた最大の学びは、
AIの使い方ではありません。
AI時代の働き方そのものだったのです。