LLMを活用する開発スタイルはどう移り変わってきたか

Last updated at 2026-08-30Posted at 2026-08-30

はじめに 💡

2022年のChatGPT登場から数年、私たちがLLMに向き合う姿勢は何度も様変わりしてきました。🌊

「良いプロンプトを書く」ことだけが競争力だった時代は終わり、今では文脈の準備、実行環境の整備、さらには仕組みそのものの設計へと、開発者が向き合うべき対象がどんどん広がっています。

この変遷を「AIパラダイムの4世代」として整理した記事がもうプロンプトを書くな──「Loop Engineering」という新しいパラダイムの正体（Across Studio Blog）です。

例えば、同じ「CIのテスト失敗を直す」というタスクでも、世代によって私たちのアクションはこれくらい変わります。👇

# 第1世代（Prompt Engineering）: 1回きりの指示を磨き込む
$ claude "このテストが失敗する原因を直して"

# 第4世代（Loop Engineering）: 条件を決めて仕組みに任せる
$ claude cron create \
    --schedule "*/30 * * * *" \
    --prompt "CIが赤くなっていたら原因調査→修正→PR作成。証拠（テストログ）がない修正はマージしない"

同じ「AIにコードを直してもらう」でも、人間がやることの中身がまったく違うことが分かると思います。✨

開発現場でのLLM活用、4つの転換点を辿る 🕰️

まず全体像です。各世代を整理すると、次のようになります。

世代 🧬	時期 🕰️	名称 🏷️	エンジニアの役割 📝
第1世代	2022〜2024年	Prompt Engineering	指示を与える
第2世代	2025年6月〜	Context Engineering	文脈を整える
第3世代	2026年2月〜	Harness Engineering	実行環境を整える
第4世代	2026年6月〜	Loop Engineering	サイクルそのものを設計する

それぞれ、開発現場でどう現れてきたかを見ていきます。👀

第1世代: Prompt Engineering（指示を与える）✍️

時期 🕰️: 2022〜2024年
代表的なツール 🧰: ChatGPT, GitHub Copilot, OpenAI Playground

背景

「Prompt Engineering」という呼び名に特定の提唱者はおらず、ChatGPT登場（2022年11月）前後からGPT-3のAPIを使い始めた実務者の間で自然発生的に広まりました。

ツールの使い方

「魔法の呪文」を探す時代でした。「ステップバイステップで考えて」「あなたは優秀なエンジニアです」といった一文の有無で出力品質が大きく変わり、プロンプトのコツをまとめた記事やチートシートが量産されました。📜

あなたは優秀なシニアエンジニアです。
以下の要件に従って、ステップバイステップで実装してください。
（要件を1つのメッセージに詰め込む）

ChatGPTはブラウザでエラーメッセージやコードを貼り付けて一問一答を繰り返し、返ってきたコードを手作業でエディタにコピー＆ペーストする、という使い方が中心でした。

GitHub Copilotはエディタ上で書きかけのコードの続きを補完してもらう使い方で、こちらは対話というよりインライン補完に近いものです。

どちらも「今のファイル」以上の文脈をモデルに渡す手段は限られていて、指示をどれだけ磨いても、モデルが持つ「前提知識」の欠如は埋められないという限界がありました。文脈やエージェント的な振る舞いは、まだ主役ではありませんでした。

第2世代: Context Engineering（文脈を整える）📚

時期 🕰️: 2025年6月〜
代表的なツール 🧰: Cursor（.cursorrules）, Claude Code（CLAUDE.md）

背景

この用語は2025年6月18日、Shopify CEOのTobi Lütke氏がXで提唱したのが起点で（該当ポスト）、約1週間後にAndrej Karpathy氏が「LLMは新種のOS、context windowはRAM」という比喩で補強したことで一気に広まりました（該当ポスト）。🚀

ツールの使い方

そこで重視されるようになったのが「何を指示するか」ではなく「何を読ませるか」でした。RAGの普及、長文コンテキストウィンドウの実用化、そしてCLAUDE.mdのようなプロジェクト設定ファイルの定着が、この流れの実装面での現れです。

<!-- CLAUDE.md の例: プロジェクトの前提をあらかじめ渡しておく -->
# コーディング規約
- テストは Jest を使用し、カバレッジ100%を維持する
- コミットメッセージは日本語で記述する
- API呼び出しは必ず `src/lib/api.ts` 経由で行う

実際のツールの使われ方としては、LangChainやLlamaIndexでドキュメントやコードベースをあらかじめベクトル化しておき、質問ごとに関連部分だけを検索して文脈に注入する、というRAGパイプラインの構築が広まりました。🧰

エディタ側でも、Cursorの.cursorrulesのように、セッション開始時に自動で読み込まれるファイルにプロジェクトの前提知識を書いておく、という使い方が定着しています。

Claude Codeも同様に、CLAUDE.mdをプロジェクト直下に置くことで、コーディング規約やディレクトリ構成、コミットメッセージのルールなどを毎回のセッション開始時に自動で読み込ませる、という使われ方をします。ユーザー単位・プロジェクト単位で階層化して置けるため、個人の好みとチームのルールを両方渡せるのも特徴です。

こうして、良い回答を得るための労力は「プロンプト職人芸」から「何を読み込ませておくか」を設計する問題へと移りました。

第3世代: Harness Engineering（実行環境を整える）🛠️

時期 🕰️: 2026年2月〜
代表的なツール 🧰: Claude Code（Sub-agents）, OpenAI Codex CLI（sandbox）, Cursor（エージェントモード）, Devin（自律実行）

背景

「Agent = Model + Harness」という図式はLangChainのブログが先に提示していたもので、これを「harness engineering」という規律として体系化したのがHashiCorp共同創業者のMitchell Hashimoto氏です（2026年2月5日「My AI Adoption Journey」）。6日後にOpenAIのRyan Lopopolo氏が実例を公開したことで 🤖、一気に業界に定着しました。

ツールの使い方

さらに、LLMが単に「答えるだけ」の存在から「ツールを使って作業する」存在（エージェント）へ進化すると、今度は**安全に・繰り返し実行できる環境（Harness）**を整えることが重要になりました。元記事はこのフェーズを「1台の機械にレールと安全柵を付ける」ことに例えています。🚧

エディタ・ターミナル・テスト実行・サブエージェントによる検証など、エージェントが安全に動き回れる「レール」を敷く工程です。Claude Codeでいえば、Skillによるプロジェクト知識の提供や、サブエージェント（Agentツール）によるレビュー・検証がこれにあたります。

# サブエージェントで実行結果を検証させる（Harnessの一例）
「実装が終わったら code-reviewer サブエージェントでレビューさせてから報告して」

実際の使われ方としては、Claude Codeではサブエージェントによる実装後レビュー、hooksによる自動フォーマット・テスト実行、MCP経由の外部ツール接続を組み合わせて「同じ間違いを二度と起こさない仕組み」を作り込みます。🧰

OpenAI Codex CLIもサンドボックス環境と自動テストを組み合わせて似た使い方をしますが、対応サーフェスの広さで評価されています。

Cursorはエディタ内のエージェントモード、Devinはより自律的なタスク実行という形で、それぞれ「harnessの厚み」の効かせどころが異なります。

どちらを選ぶかより「どういう作業の流れに自分を合わせたいか」で選ぶツールになってきています。

第4世代: Loop Engineering（サイクルそのものを設計する）🔁

時期 🕰️: 2026年6月〜
代表的なツール 🧰: Claude Code（/goal, /schedule）, OpenAI Codex（automations）

背景

きっかけはClaude Code責任者Boris Cherny氏の発言です。🔍 2026年6月2日、WorkOS主催の「Acquired Unplugged」で

I don't prompt Claude anymore. I have loops that are running...My job is to write loops.
（もうプロンプトは書かない、仕事はループを書くことだ）

と発言し、同時期に開発者Peter Steinberger氏も同様の主張をしていました。

これを受けて2026年6月7日、GoogleのAddy Osmani氏がエッセイ「Loop Engineering」でこの実践に名前と構成要素（automations・worktrees・skillsなど）を与えました。💡 つまり名付け親はCherny氏ではなくOsmani氏です。

なお「30日間でPRの100%をClaude Code自身が書いた」逸話は2025年12月27日のThreads投稿、「IDEを削除して以来開いていない」逸話は2026年6月9日のX投稿が出典です。

ツールの使い方

そして現在地が第4世代、Loop Engineeringです。Harnessが「1台の機械の安全装置」だとすれば、Loopは「工場全体を自律的に回す生産管理システム」に相当します。🏭

人間がプロンプトを打つたびに起動するのではなく、時刻・イベント・条件に応じてエージェントが自律的に起動し、証拠に基づいて判断し、終了条件に従って止まる——そこまでを含めて設計するのがLoop Engineeringです。

この設計を実際に支えているのが、Claude Codeの/goal（合格条件を満たすまでエージェントを走らせ続けるコマンド）や/schedule（クラウド上での定期実行）、そしてOpenAI Codexのautomations機能です。🧰

実際の使い方としては、/goalに「テストが全部通るまで直して」と合格条件だけを渡して放置したり、/scheduleやCodexのautomationsで「毎朝CIの赤を調査して修正PRを出す」といったタスクを定期実行させたりする形です。

いずれも「人間がプロンプトを打つ回数」ではなく「エージェントが自律的に動く時間」を増やすための機能という共通点があります。

さいごに 🎯

大事なのは呼び名を覚えることではなく、指示 → 文脈 → 実行環境 → サイクルと、価値の重心が一貫して「モデルに何を言うか」から「モデルの外側に何を作るか」へ広がり続けているという構造そのものを掴んでおくことだと思います。

LLM活用は Prompt → Context → Harness → Loop という4世代を経て進化してきた
現在地であるLoop Engineeringは「良い指示」ではなく「良い仕組み（サイクル）」を設計する技能が問われる時代

自分の開発フローが今どの世代の延長線上にあるか、一度棚卸ししてみると、次に投資すべきスキルが見えてくるかもしれません。✨

参考リンク 🔗

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up