リサーチ、執筆、デザイン、コード。かつて数日かかっていた仕事を、AIはいまや数分でこなします。それでも多くの人は、AIの出力が正しいことを願いながら使っているのが実情です。ループエンジニアリングは、その「願い」をプロセスに置き換える働き方です。AIは自分の仕事をループの中で確認し、改善する。判断は人が持つ。そしてルール、チェック、ワークフローからなるハーネスが、全体を一定の水準に保ちます。ここでは、その仕組みを実例とともに紹介します。題材は、私がリードし、現在アプリストアで公開されているモバイルアプリです。
AIを使った仕事の多くは、「願い」頼みです。 指示を出し、何かが出てきて、それが正しいことを願う。
AIの出力の質は、それを確認する人の力量で決まります。コードが読めなければ、安全かどうかは判断できません。デザイナーでなければ、その画面が通用するかどうかは分かりません。分野の知識がなければ、そのリサーチが確かかどうかも分かりません。だから、願いながら出すか、出すのをやめるかのどちらかになってしまいます。
仕事が、自分で自分を確かめる。 AIが作業し、確認し、直し、うまくいかなかったことから学びます。
ループエンジニアリング はプロセスです。手順を一つずつ指示するのではなく、タスクをまるごとAIに任せます。AIはタスクに何が必要かを見極め、足りない情報を集め、作業し、チェックし、見つけた問題を直します。自分で判断できないときだけ人に確認します。判断は人が担い、繰り返されたミスはハーネスの改善につながります。それを可能にするのが ハーネス です。AIが作業の拠り所にするルール、ガードレール、ガイド、スキル、チェック、メモリのことで、その中身は「何が良いか」を知っている人の知見から作られています。この2つがそろえば、自分のスキルを超える仕事に取り組めるようになり、時間を判断に使えるようになります。
ループエンジニアリングは、AIが関わるあらゆる仕事に使えます。リサーチ、執筆、デザイン、分析、運用、ソフトウェア開発。形はどれも同じです。中心にあるのは目標と方向性で、これは人が持ちます。そこから複数のループが伸び、それぞれ違う速さで回って、また中心に戻ってきます。そして全体をハーネスが包んでいます。ソフトウェア以外で試すなら、 Harness Kit を使えば、いま仕事をしているフォルダやリポジトリ、ワークスペースにハーネスを組み込めます。
例 · プロダクト開発の場合
AIは要件や仕様、デザインなど必要な情報を受け取り、クリックできるプロトタイプを作ります。人はそこで示された方向性を、デザインが1案のときも複数案のときも評価し、進む方向を決めます。その結果、デザインが変わることも、要件そのものが変わることも、新機能が加わることもあります。要件を更新し、固まるまでこれを繰り返します。
人の役割： プロダクトを使う人たちとAIの橋渡し役です。このループに最も多くの時間を使うことになります。
AIが要件をもとに作ります。要件とハーネスに照らして自分の仕事を確認し、問題を直し、また繰り返します。人が見張っている必要はありません。
人の役割： 明確な要件と良いハーネスで土台を整え、次に何を作らせるかを決めること。
小さなループ：自己改善。 構築ループの横で、ハーネスは経験から良くなっていきます。AIが自分で問題を見つけることもあれば、人が問題を指摘してAIにフィードバックすることもあります。どちらの場合も、ルール、スキル、チェック、ワークフローといった形でハーネスを改善でき、次の構築はより良い状態から始まります。
これはAI支援のQA、つまり品質チェックです。AIは変更ごとに承認を依頼します。レビュー担当のAIがテストし、修正や改善が必要なら差し戻します。人はそのレビューに目を通してから承認し、承認された変更が反映されます。
人の役割： AIのレビューに目を通して承認すること。そして、何度も起きる問題をハーネスの改善につなげること。
3つのループはすべてハーネスに包まれていて、どこかのループで学んだことは、すべてのループに効くルールになります。私のプロジェクトでは、構築とレビューは速く進みました。時間がかかったのはステークホルダーとの定義と改善で、重要な判断はそこで下されていました。
Andrew Ng「Three Key Loops for Building Great Software」をもとに構成。所要時間は私のプロジェクトの実績です。
例として取り上げるのは、私が大規模な組織向けにリードしたモバイルアプリです。何をなぜ作るかを決め、AIの作業を方向づけ、次はもっと良くなるようにフィードバックしました。変更の大半は私が出していて、エンジニア1件に対して私がおよそ2.5件という割合です。私の変更はAIレビューを通ってからエンジニアが承認し、エンジニアの変更は同じやり方で私がレビューしました。バックエンドは別チームの担当で、アプリはそこに接続していました。AIが作業の拠り所にするすべて、つまりハーネスが、そのすべてを支えていました。下の4つのステップは、上のループを順に追ったものです。ステップ2が定義と改善、ステップ3が構築、ステップ4がレビューと承認にあたります。
横にスワイプすると、4つのステップをすべて見られます →
私の仕事は、AIが必要なコンテキストを持っている状態をつくり、そのうえでAIの作業を方向づけることでした。細部まで自分ですべて確認することはできません。だから「何が良いか」を書き出し、AIがそれに照らして自分で確認できるようにしました。問題が起きたときは、画面だけでなくハーネスも直しました。
AIが良い仕事をできるのは、適切なコンテキストがあるときだけです。私の仕事は、AIがそのコンテキストを持ち、作業を始める前にタスクを理解している状態をつくることでした。
ハーネスは単一のものではありません。ルール、ガードレール、ガイド、スキル、ワークフロー、チェックなどが増え続けるコレクションです。エンジニアと私の二人で管理し、私はデザイン以外でも改善点に気づくことがよくありました。
コンテキストとタスク、そして明確な完了の定義があれば、AIは作業し、チェックし、問題を直し、完了まで進み続けます。それでも細部、特に最終的な画面は自分でも確認しました。
これが自己改善のループです。問題は2つの経路で見つかりました。
どちらの場合も、ハーネスが改善されます。新しい、またはより良いルール、スキル、チェック、ワークフローが加わるのです。ほかの変更と同じように承認を経るので、次のタスクはより良い状態から始まります。
良いデザインとは何かを、AIが従える平易な言葉で書きます。自分の頭の中にあるだけでは、AIは使えません。
自動チェックでは、画面が「しっくりくるかどうか」は分かりません。そこは私の役割として残しました。
同じことを2回直したら、それはルールにします。AIが従えるよう、ハーネスは短く保つようにしています。
これは、私がオープンソースで公開しているハーネスの1つ、 Harness Kitでの話です。テストがすべて緑なら大丈夫だと思っていましたが、もっと乱暴な方法を試してみました。チェックを1つずつ削除して、そのたびにテストを実行したのです。すると、2つのチェックは削除してもテストがすべて通りました。そのうち1つは、ファイル名を使ってハーネスが信頼する記録を偽造されるのを防ぐ、唯一の仕組みでした。
2回の入念なレビューでも、どちらも見落とされていました。削除を1回試しただけで、数分で見つかったのです。今ではルールにしています。チェックを追加したら、それを削除してテストが失敗することを確認する。実際の画面を見るのと同じ教訓です。失敗したときに検知できて初めて、合格に意味が生まれます。
ハーネスは、身近にいないかもしれない専門家の判断力も与えてくれます。執筆ならスタイルガイドとファクトチェック、リサーチなら情報源についてのルール。プロダクトなら、データベースを安全に変更する方法や、ログインを安全にする方法を自分で知らなくても構いません。ハーネスが知っていて、AIはそれに従います。プロダクトの各レイヤーで見ると、次のようになります。
上のアプリでも、私はこのやり方で進めました。私はフロントエンド開発を本業にしているわけではありません。それでもUX、UI、フロントエンドを本番品質まで仕上げられたのは、私が方向を示し、良し悪しを判断できる基準に、ハーネスがAIを従わせてくれたからです。コードを一行ずつ自分で書く必要はありませんでした。バックエンドは別チームの担当でした。私がオープンソースで公開している Universal Harness は、ここに挙げたすべてのレイヤーを、Web、モバイル、バックエンドのスタックを問わずカバーできるように作っています。各ゲートには、違反をわざと起こして、確実に検出されることを確かめるセルフテストが付いています。
私は自分の役割を、決まった職種として捉えていません。プロジェクトに必要なことに合わせて変わります。今回は要件定義、デザイン、そしてAIへの指示でした。普通なら複数の専門職で分担する仕事です。
AIエージェントと働くとき、職種はそれほど重要ではなくなります。大事なのは線引きを理解することです。どの作業を人が判断して行い、どの作業を人がAIと一緒に行い、どの作業をAIが自律的に行うのか。そのうえで、いつ、なぜ人が介入すべきかを決めます。
たとえば、ある画面デザインを作る必要があるとします。AIに指示するのは、必ずしもUIデザイナーでなくて構いません。最初のステップはほかの人でもできます。ただ、完成した画面はUIデザイナーに確認してほしいかもしれません。別のプロジェクトなら、自動チェックで十分な場合もあるでしょう。プロジェクトと、そこで何が必要かによって変わります。
実際の画面の確認のように、必ず担当者の名前を明示しておくべきものがあります。誰も確認しなければ、すべてのチェックに合格した仕事でもおかしな見た目のまま世に出てしまい、それを知らせてくれるものは何もありません。
「AIが知らないことを人が知っている限り、人は関わり続ける必要がある」Andrew Ng「Three Key Loops for Building Great Software」より要約
私は自分の時間を、2種類の仕事に分けました。一つは作る作業（画面づくりを含む）。もう一つは戦略・探索・改善で、要件を詰めること、デザインを探ること、ステークホルダーやユーザーとアイデアを検証することです。
「AIのおかげで、より価値のある仕事に時間を使える」と言うのは簡単です。このプロジェクトでは、それが具体的な形で起きました。時間配分が逆転し、仕事の中身そのものが変わったのです。
仕事はこう変わりました。
固まったように見えて、固まっていなかった要件。 要件の多くは、実は未確定だったり、優先順位がなかったり、まだ変わり続けていたりしました。それを早い段階で見つける時間がありました。
1つの課題に、複数のデザイン。 ドキュメント上で1案を議論するのではなく、動くプロトタイプとして作りました。
ステークホルダーやユーザーとのテスト。 作るものそのものが変わるほど、何度も繰り返しました。
方向転換も吸収できた。 途中でアプリの核となる部分が変わりました。それでも影響は約2週間で済みました。作る作業に時間がかからなくなっていたからです。
一般的なプロジェクトで同じ結果を出そうとすれば、作る作業にも同じか、それ以上の時間をかけることになります。多くの場合、チームはその代わりに、この価値の高い仕事のほうを削ってしまいます。
新たなボトルネックも見えてきました。人が関わるステップです。AIが数分で作れるなら、フィードバックや承認を何日も待つことの重みはずっと大きくなります。
速さは、変化のほんの一部にすぎません。1人でカバーできる範囲が広がり、プロダクトを使う価値のあるものにするための判断に、より多くの時間を使えるようになりました。
これらは、ループエンジニアリングで開発した実際の本番アプリで計測した結果です。1つは60画面を超える先行のモバイルアプリ、もう1つは私がリードしたアプリで、どちらも公開中です。プロダクト名は伏せています。
先行アプリ · AIなしの半年とAIありの半年
期間全体を通じて、AIによる捏造コード（実在しないものをそれらしく書いたコード）はゼロでした。AIが書くコードで、特に心配されることの多い失敗の1つです。
AIが自発的に作成したテスト改善のうち、採用された割合。1か月で82件を作成しました。
コード品質の総合スコア。2つの期間を同じ方法で計測しています。
型エラー（バグの芽）がゼロに。重複コードも9.4%から8.1%に減りました。
追いつかなかった部分もあります。 不要コードの整理は、新しい作業のペースに追いつきませんでした。成果を示したのと同じスコアが、この弱点も示しています。
私がリードしたアプリ · 最初の3週間
私の変更のうち、AIレビューで少なくとも1回は差し戻されたものの割合（40件中26件）。レビューがきちんと機能していた証拠です。
変更1件あたりの平均レビュー回数。指摘、修正、再レビューを、通るまで繰り返しました。
25件の変更に付いたレビューコメントを振り返り、繰り返し起きていた問題を2つ見つけました。どちらも新しいルールになりました。
2回目の振り返りでは、コードレビューでは拾えない実機での確認項目が加わりました。キーボードを開いたときのフォームの挙動です。
エンジニアの時間の使い道。 エンジニアの仕事は、目に見えにくい場所に移りました。ハーネスのメンテナンス、ルールの文書化、そして私が速く安全に進めるための自動化づくりです。新しいルールで同じ問題が実際に減るかどうかは、まだ計測中です。
ここに計測した比較はありません。同じアプリをハーネスなしで作った人はいないからです。ただ、仕事の進み方の違いははっきりしています。ハーネスがなければ、AIへの指示がもっと必要になり、手順も抜けやすく、構築にかかる時間もここまでは減らなかったと思います。
| 項目 | ハーネスなし | ハーネスあり |
|---|---|---|
| 「自分の作業をレビューして」などの手順 | 毎回、自分で覚えて指示する | 組み込まれていて、自動で実行される |
| 手順の抜け漏れ | 抜けやすい | 一度書いておけば済む |
| 品質 | AIに指示する人次第 | 誰でも同じルールとチェック |
| 学び | 一人の頭の中に留まる | ハーネスに蓄積され、次に活かせる |
| 私の時間 | 一つひとつの手順の指示に使う | 判断、レビュー、フィードバックに使う |
ハーネスは、毎回ゼロから作る必要はありません。コアになるハーネスから始め、各プロジェクトに自分たち用のコピー（フォーク）を持たせて、その仕事に合わせて育てていきます。あるプロジェクトで見つかった改善はコアに戻せるので、ほかのプロジェクトにも届きます。
ルール、スキル、チェック、デザインガイダンスが初日からそろっています。私がオープンソースで公開している Universal Harness は、その出発点になるように作っています。
コアのハーネスでミスを一度直せば、それをもとにしたすべてのプロジェクトに修正が届きます。
AIに慣れていない人でも同じルールとチェックで作業するので、手順が抜けにくく、品質の基準もそろいます。
どのプロジェクトで生まれた修正や追加もコアに戻せるので、直接は関係のないプロジェクトの改善が、自分たちの使うハーネスを良くすることもあります。
私のプロジェクトでは、ほとんどの場面でハーネスはニーズに合っていました。柔軟なので、プロジェクトに応じて追加、改善、拡張もできます。ベースのハーネスにもプロダクトやデザインのコンテキストは一部含まれていましたが、主に開発などの技術的な領域に重点を置いたものでした。そこで作業を進めながら、プロジェクト固有のプロダクトのコンテキストと、デザインやブランドのコンテキストを追加していきました。これらはハーネスの中核になる要素だと感じています。たとえば、ハーネスの初期セットアップの段階でこうした情報を集めたり、あれば提供を依頼したりできるとよいかもしれません。
規模の大きいプロジェクトや、リサーチやプロダクト企画なども含む幅広いプロジェクトなら、その範囲をカバーするスキルやガイドを増やすことになるでしょう。ただ、すべてのハーネスがあらゆる種類の仕事をカバーする必要はありません。プロジェクトに必要なものを加えていけばよいのです。
これらの学びは、主に1つのプロジェクトから得たものです。本当の検証は、次にハーネスを使うプロジェクトです。測る価値があるのは2つ、立ち上がりの速さと、レビューのやり取りの回数が時間とともに減っていくかどうかです。
多くはAIを使うあらゆる仕事に当てはまりますが、企業向けに本番アプリを作る場合は特に重要です。
ハーネスがどれだけ良くても、AIは間違えることがあります。結果に影響する要素はほかにもたくさんあります。自分で確認できるものは確認し、自分の専門外の仕事は、適切な人やチェックが見るようにしましょう。
キー、パスワード、アクセストークンをAIが読んだり使ったり、チャットに貼り付けたりできないように設定しましょう。個人情報やその他の機密情報も同様です。対策をしていても、絶対に大丈夫だとは思わないこと。常に注意を払いましょう。
AIは、完了がどういう状態かを分かっているときに一番力を発揮します。毎回プロンプトに書く必要はありません。Issue、PRD、仕様書に書かれているかを確認するか、AIに追記を頼みましょう。
機能追加や大きめの変更では、構築を始める前にAIに計画を示してもらい、不明点を質問させましょう。小さな修正なら、そこまでは不要なこともあります。
セッションが長くなるほど、1ステップあたりのコストが増え、AIの仕事の質も落ちていきます。把握しておかなければならない情報がどんどん増えるからです。
1つの機能や1ページのデザインなど、1つのセッションでは1つのタスクだけを扱うようにしています。プルリクエスト（PR）の管理も楽になります。10件以上開いていると、どのセッションがどのPRを担当しているかを覚えておくのはとても大変です。1セッション1PRと考えるとシンプルですが、厳密なルールではありません。小さなPRを1セッションで2つ扱うのは問題ありません。
マージは、AIがミスをして作業を失ったり巻き戻したりしやすいポイントです。ほかにも進行中の作業があるかもしれないこと、前回のマージ以降にmainブランチが進んでいるかもしれないことを、AIに理解させておきましょう。ハーネスのガードレールも役立ちますが、100%の保証ではないので、結果を確認しましょう。
セッションが長くなってきたら、終わったこと、次にやること、注意点をまとめた短い引き継ぎメモをAIに書いてもらいましょう。そして、そのメモから新しいセッションを始めます。
Issueは、タスク管理、特にバグ修正やデザイン改善の管理に最適です。AIにレビュー、整理、優先順位付けを手伝ってもらえますし、各プルリクエストを対応するIssueに簡単に紐づけられます。
どの作業を人が行い、どの作業を人がAIと一緒に行い、どの作業をAIに任せられますか？ いつ、なぜ人が介入する必要がありますか？
変更が承認される前に、実際の画面を見るのは誰ですか？ 何を新しいルールにするかを決めるのは誰ですか？
目標、要件、タスク、そして「完了」がどういう状態か。いま、何が足りていませんか？
作るのに数分、決めるのに1週間かかるなら、速くすべきなのは作る作業ではありません。
ルールが画面にはあっても、データやセキュリティにないなら、AIはそこで推測に頼ります。うまくいかなかったときに、いちばん痛手の大きいレイヤーから始めましょう。
それはハーネスを改善するチャンスです。ルール、スキル、チェック、ワークフローを加えれば、次からは言われなくてもAIが正しくこなせます。
さらに詳しく知りたい方のための補足です。
| サイクル | チームが以前からしてきたこと | AIで変わること |
|---|---|---|
| 作る | 少し作り、確認し、繰り返す | AIが数分でこなす。人はそこから手を離す。 |
| 確認 | 同僚どうしでレビューする | 最初の確認はAIが行う。判断が必要な部分は人が持つ。 |
| ユーザーから学ぶ | ユーザーに試してもらい、改善する | やることは同じ。ただ、いまはここがいちばん時間のかかる部分になる。 |
| 働き方を改善する | 一緒に振り返り、変えることを決める | 変えることは、AIが従えるように書き出す必要がある。 |
これらのサイクルは、ほかでも詳しく解説されています。Andrew Ngは、それぞれにかかる時間（数分、数時間、数週間）で分類しています。このページでは、仕事を方向づける人の視点、つまりAIが作っている間に人が何をするかという視点から見ています。
構築のループの中では、AIが推測で進めずに止まって確認すべき場所を、良いハーネスがあらかじめ決めています。計画を1つ入れると、出てくるのは承認待ちの変更か、AIが止まった具体的な理由のどちらかです。早めに止まるのは遅く感じますが、直すのにいちばんコストがかからないタイミングです。