ブランク明けのWebエンジニアが実践した、対話型コード生成からループエンジニアリングへの移行

2026.10.22#生成AI #Web開発 #開発体制 #受託開発

数年のブランクを経て、パーティーハード株式会社への入社を機にWeb開発へ復帰した際、現場では端末上で自律的に動作するClaude Codeがすでに導入されていました。それまでの私はAIを使った開発をまったく経験しておらず、この新しい開発環境への適応から始めることになりました。

手作業中心の開発経験と復帰時の課題

かつてWeb開発に携わっていた頃は、公式ドキュメントや技術記事を検索しながら、手作業でコードを書いていました。そうした開発しか経験していなかったため、復帰当初はClaude Codeに対する指示の粒度がつかめず、誤った指示によって予期せぬコードの書き換えが発生するのではないかという懸念を抱いていました。

さらに、入社後に携わった案件では、Next.jsとTypeScriptを中心に、ORMによる型安全なスキーマ管理やサーバーレスの実行環境など、それまでほとんど触れたことのない技術が採用されていました。そのため、これらの技術に関する知識が不足した状態で実務に入ることになりました。

対話型のコード生成とその限界

最初は、Claude Codeを対話的なプロンプト入力ツールとして扱い、チャットのようにそのつど指示を出してコードを生成させていました。Next.jsの画面コンポーネントやORMのスキーマ定義などを出力させるため、前提条件や制約を指示文に書き込み、対話を重ねながら生成していました。

この方法でも、指示文を整えれば意図に沿ったコードは出てきます。しかし実際のアプリケーション開発では、関連する型定義やルーティング、既存の共通関数など、複数のファイルにまたがる依存関係や整合性を維持する必要があります。Claude Codeはプロジェクト内の複数ファイルを参照できるものの、対話的な使い方では、一回の指示ごとに人間が差分を読み、周辺コードとの整合性を手作業で確認しなければなりません。その結果、指示文の調整と周辺コードの確認に多くの時間を費やすことになり、開発の進行が、手作業による確認の速度に制約されていました。

また、AIに任せるより自分の手で直したほうが早い作業もありました。フォントサイズや余白の調整のように、細かなデザインに関わる部分は、指示文で伝えるよりも、ブラウザの検証機能で見た目を確かめながら手作業で修正したほうが試行錯誤の時間が短く済みます。

自律ループの仕組み

こうした停滞を解消するため、チームではAI自身に「分析」「計画」「実装」「レビュー」「テスト」の各工程を繰り返させる、自律ループによる開発手法を取り入れました。AIが実装・検証・修正を自律的に繰り返せるよう、終了条件や工程をあらかじめ設計するこの手法は、プロンプトエンジニアリングやコンテキストエンジニアリングに続く考え方として、2026年半ばから「ループエンジニアリング」と呼ばれるようになりました（参考: ＠IT「ループエンジニアリングとは？チャットとAIコーディングの往復から卒業する新しい開発スタイル」）。個々の指示文ではなく、AIを動かし続けるループそのものの設計に焦点を当てる点が特徴です。

開発者が要件と受け入れ条件を定めたタスクを用意すると、AIが既存のコードを読んで計画を立て、実装し、テストと型チェック、静的解析がすべて通るまで修正を繰り返します。別の役割を持ったAIがレビューして差し戻すところまで含めて、プルリクエスト（以下、PR）を作るまでをAIが担当します。

これはClaude Codeの単一の標準機能だけで実現されるわけではありません。チームでは、ループ全体の手順を、Claude Codeに標準で備わるスキル機能（作業手順をまとめた指示書）として定義し、その手順に沿って、同じく標準機能であるサブエージェントを、要件分析、実装、レビューといった役割ごとに順に呼び出しています。Issueの状態の切り替えや作業ディレクトリの作成など、定型的な操作は小さなスクリプトに切り出しています。

この仕組みにより、受け入れ条件が明確なタスクであれば、タスクを渡すだけで一つの機能の実装からテスト通過までが自律的に進みます。

未経験の技術スタックで自律ループが機能する仕組み

ループを使うようになって一番助かったのは、触れたことのない技術でも前に進めることでした。タスクを起票する際は、開発者が実装したい内容をClaude Codeに入力すると、エージェントが既存コードを走査し、仕様上の不明点を開発者に問い返します。その対話を通じて受け入れ条件を明文化し、タスクとして登録します。ループの中では、実装を担当するサブエージェントがこの受け入れ条件をもとに、プロジェクトのテスト規約に沿ってテストコードを書き、そのテストと既存のlint設定・型チェックで合否を判定します。仕様の判断は開発者との対話で、実装の作法はプロジェクトの既存の規約とコードで担保されるため、私自身が記法や周辺ツールの作法に習熟していなくても実装を進められ、調べ物と実装にかかる時間は大きく減りました。

記法を調べたり書き方を試行錯誤したりする時間が減った分、仕様や設計の判断に時間を充てられるようになりました。ただし、それは技術の理解が不要になったという意味ではありません。生成されたコードが仕様どおりかを判断する責任は、開発者に残ります。

この経験を通じて、私の作業の比重は実装そのものから、次の3つに移っていきました。

受け入れ条件の定義: 機能が満たすべき振る舞いを、対話を通じて明文化する
終了判定基準の整備: テスト・型チェック・lintのどれを通過すればループを終えてよいかを定める
タスクの粒度分割: ループが収束する大きさにタスクを分ける

自律ループで生じる品質リスク

テストや仕様の前提が曖昧なままループを回すと、一見正しそうで要件を満たさないコードが生成され続けたり、不必要な修正が広い範囲に及んだりします。また、テストの通過だけを終了条件にしてループを回すと、アサーションを満たすためだけに例外を握りつぶしたり、値をハードコードで返したりするコードが生成されることもあります。

レビューの工程をAIに任せても、この問題は消えません。レビューを担当するサブエージェントは、実装前に立てた計画や要件に沿っているかを基準にコードを評価します。そのため、計画や要件そのものに仕様の抜けや権限の境界の不備があると、実装がそれに沿っている限りレビューも通過してしまいます。特に認可漏れのように、lintも型チェックもテストも通り、画面上も正常に見える不具合は、ループの中ではなかなか検出されません。

PRを作成した後に外部の自動レビュー（当チームではGitHub Copilotのレビュー機能）を併用しても、AIによるレビューは基本的にPRごとに独立して行われ、過去のPRで受けた指摘の内容は次のレビューに引き継がれません。そのため、AIのレビューを重ねても、同じ誤りが繰り返される可能性は残ります。

人間とAIの責任分界

こうした限界があるからこそ、判断と実装の担い手を分けています。

ログイン（認証）や権限管理（認可）、決済、データベースのマイグレーションのように、見落としたときの影響が大きいタスクは、ループの手順上「判断が必要な内容」として扱い、方針が定まっていなければAIは着手する前に止まります。こうしたタスクでは、どの権限で何を許可するか、二重課金をどう防ぐかといった方針を開発者が先に決めて要件に書き込み、そのうえで実装をループに任せています。

権限チェックのうち、機械的に確認できる部分はテストで押さえています。たとえば管理画面を持つアプリでは、保護すべきページすべてに、認証とロールを確かめるガード処理が呼ばれているかを自動テストで検査しています。一方、ロールの指定が仕様どおりか、利用者が他人のデータにアクセスできてしまわないかといった認可制御の妥当性は、ガード処理の有無を確認するこのテストでは判定できません。

そのため、マージする前には、開発者が手元で実際に動かし、権限ごとに表示や操作が仕様どおりに制限されているか、データが正しく扱われているかを確認します。方針を決めることと、その結果を確かめることは、今も人間の仕事です。