AIエージェントに「この帳票をRubyで再現して」と頼んだら、10分で「できました」と返ってきました。人間がやれば丸2日かかる仕事です。
ただ、出来上がりは40点でした。罫線はずれ、色は再現されていない。それっぽいけれど、元の帳票とは別物です。
AIは「速く動くもの」を作ろうとする
複雑な罫線やセルの結合、微妙な座標の帳票でした。人間なら線を一本ずつ合わせていく地味な作業ですが、AIはそうしません。全体をざっと捉えて、素早く形にしてくる。
「帳票をRubyで作って」という指示を、AIは「帳票らしきものを作る」と受け取ったわけです。私たちが求めていた「元の帳票と見分けがつかないもの」とは、ゴールの精度がまるで違いました。
ゴールの精度を変えたら、結果が変わった
そこで指示を変えました。「速さは要らない。元ファイルと見分けがつかないクオリティで、90点でPRを出して」。
これだけで結果が変わりました。罫線の位置を合わせ、色を再現し、余白まで気を配ってくる。返ってきたのは80点です。残り20点を人間が直して、トータル2時間で終わりました。丸2日が2時間です。
指示の中身は最初とほとんど同じです。変えたのは、ゴールの精度だけ。AIの生産性を決めるのはAIの性能ではなく、こちらが渡すゴールの精度なのだと実感しました。
検証を組み込むと、もう一段上がる
検証の指示を足すと、さらに精度が上がります。「作って終わり」ではなく、「作ったら元ファイルと見比べ、差分があれば直す」という流れを組み込む。
弊社が使っているCursorというツールでは、この検証を補助エージェントに任せられます。このとき使ったのはComposer 2.5という、Cursorの中でも最上位ではないモデルでしたが、それで十分な精度が出ました。良いものを作るのに、最新・最高のモデルは必須ではありません。指示と検証をきちんと設計すれば、手頃なモデルでも実用レベルに届きます。
ループエンジニアリングという考え方
この「ゴールを決め、検証しながら繰り返す」やり方には、最近「ループエンジニアリング」という名前がつきました。2026年6月にGoogleのAddy Osmani氏が提唱した考え方で、AIに毎回指示を出すのではなく、ゴールに届くまでAIが自分で回り続ける仕組みを設計する、という発想です。
使いこなすコツは、難しいツールを覚えることではありません。何を完成とするかを決め、達成できたかを確かめる基準を用意し、届かなければやり直させる。この3つを設計するだけです。今回の帳票なら、「元ファイルと見分けがつかない」がゴール、「見比べて差分がない」が検証基準にあたります。
大事なのは、ゴールを定義する側の力
AIに「作って」と言えば、何かは出てきます。問題は、何が出てくるか。曖昧な指示からは曖昧なものが、精度の高いゴールからは精度の高いものが出てきます。
お客様にとって大事なのは、AIを使ったかどうかではなく、出来上がったものの質です。その質を決めるのは、AIの性能よりも、ゴールを定義する側の力だと考えています。
藤沢市で一番技術力の高いシステム会社を目指して、弊社は日々研鑽を積んでいます。システム開発や技術に関するご相談がございましたら、どんな小さなことでもお気軽にお問い合わせください。
