こんにちは。公認会計士・税理士の富村亮超です。

今日は、最近よく聞くループエンジニアリングについてです。

ループエンジニアリングとは、ゴールを定めて、そのゴールにたどり着くまで検証と再実行をAIエージェントが自動で繰り返すことを言います。

 

ループエンジニアリングを一言で言えば、「鑑真」です。

 

鑑真は、中国から、日本を目指して5回渡航に失敗し、6回目でようやく日本にたどり着きました。

5回の間に、様々な反省をしたでしょう。

方角の精度、船の操舵術、天候の読み、季節、食糧問題。

これらの検証を経て、ようやく6回目で日本へとたどり着きました。

 

では、ここで鑑真に3回で日本に到達してもらいましょう。

そのために、鑑真に高性能な六分儀と、電波時計と、船の速度計をプレゼントしましょう。

そうすれば鑑真はある程度正確な方角と時間を知ることができ、3回のループで日本につけました。

 

鑑真に1回で日本に着いてもらいたい場合。

より良いループエンジニアリングとして鑑真にGPSを渡します。

すると、現在地が分かるので、検証サイクルが非常に早くなります。

最初は変な方角に船が出ていって、波に流され、風に流されるかもしれませんが

GPSがあれば問題ありません。かなり早く、およそ1回で日本に到達できるでしょう。

 

鑑真に、検証設備としてどういう設備を渡すか、これがループエンジニアリングの肝です。

 

ループエンジニアリングとは、鑑真を鍛える話ではないのです。

 

 

会計および監査に話をスライドしましょう。

ここでいう、会計とは、正しい決算書を作成する営みとします。

その過程には様々な検証が入ります。

貸借はあっているか、マイナス残高はないか、元資料とは合っているか、残高は銀行の残高確認書と一致しているか。

これらのチェック項目は、どれもループエンジニアリングでいうところの「検証」に他なりません。

数々の検証を経て、最終的にたどり着く決算書がループエンジニアリングのゴールです。

 

ではここで、ループエンジニアリングにおいてボトルネックと言われているものは何だと思いますか。

それは、仕訳の入力作業者自身のレベルではなく、「検証」のレベルです。

チェック項目がガバガバだと、どれだけ検証(笑)を頑張っても、ろくなものは出来ないのです。

一方で、チェック係さえしっかりしていれば、1年目の人がどう作っても、(周回数はかかるにせよ)最終的には良い決算書が出来るはずです。

つまり、チェック係がチェック係としてどれくらい能力が高いか、ここが今ホットな「評価」という概念です。

 

ここで、2026年現在までに流行したAIエンジニアリングのキーワードを時代の変遷とともに会計になぞらえて解説します。

 

• 2023年：プロンプトエンジニアリング（1回の指示文が勝負だった時代）

プロンプトエンジニアリングは、仕訳入力作業者に対して、「どういう指示を出すか」が仕訳の速度・品質を左右するという考え方です。

当時のAIはこちらの意図を読み取る能力も、事前知識も少なく、ありていに言えばバカだったので、どういう指示を出すかで全然成果が違いました。

 

• 2024年：RAG（知識の渡し方が勝負に）

RAGは、作業者が仕訳を切るたびに、その取引に関係するマニュアルのページだけを資料室から探して渡す、という考え方です。

事前に全部のマニュアルを渡しても作業者が全部読み切れなかったりするので、このような都度方式が採用されました。

 

• 2025年：コンテキストエンジニアリング（文脈の設計が勝負に）

仕訳マニュアルがクソだと作業者もやる気をなくすので、そもそも仕訳マニュアルをどういうものを渡して、どういう部分は削るか

これまでの作業のログや日報も作業者に見せるべきか。日報の管理はどうするか。マニュアルは書庫に置いておくか、PCですぐみられるようにしておくか。

こういった内容を考えるようになったのがコンテキストエンジニアリングという考え方です。

このころ、エージェントという、ある程度自分で調べたり考えたりして、決算書を完成させようという作業者が採用市場に多く出回りました。

 

• 2025〜26年：ハーネス、ループエンジニアリング（反復と足場の設計が勝負に）

作業者が決算書を頑張って作ってくれるのですが、その際の道中のフィードバック係がクソだとろくなものが上がってこないので

そもそもそのフィードバック係にしっかりした奴を配属しよう。というのがループエンジニアリングの考え方です。

また、そもそも会社の環境として、作業者が扱うシステムや会計ソフト、あるいはPCなどの設備をWindowsにすべきか、Macにすべきかなど、会社の設備を何にするのがいいか考えていこう、あるいは会社にある情報資産をちゃんと設計しよう、というのがハーネスエンジニアリングという概念です。

 

• 2026年　評価エンジニアリング

ループエンジニアリングの過程で、作業者ではなく、フィードバック係がしっかりした奴なのか、それを人事評価するようになりました。

しかし、一方で、そのフィードバック係の人事評価システムをどのようにつくるかが難しい。

これが2026年の最新の課題、評価エンジニアリングとなっています。

 

これらの中で、ずっと一貫しているものがありまして、それは「作業者のレベルは所与」だということです。

この作業者のレベルというのが、みなさんご存じ　AIのモデルというやつです。

Opus4.8だとか、GPT-5.6だとか、GeminiPro3.1だとかいう、あれです。

作業者のレベルは時代とともに変わるので、作業者のレベルが一定としたうえで、どれだけ高品質な成果物を作れるか

この4年間、AIの世界で流行っていることは、一見違うように見えて、ずっと同じことをテーマにしていたんですね。

 

ちなみに、ハーネスという言葉がめちゃくちゃ流行ってるので、「モデル」と「ハーネス」の違いを解説しておきます。

モデルは先ほど述べたような、Opus4.8とかです。

優秀なタイミーさんだと思ってください。

 

ハーネスは、「claude code」や、「genspark」、「codex」などがハーネスで、タイミーさんの作業場のイメージです。

ちなみに、Claudeの中のチャット欄や、GPTのチャット欄も全部ハーネスの一種です。

 

これが分かれば、

「Gensparkはclaudeのモデルが使えるので、claudeのMAXプランを契約する必要がないですよ」

と言ってる人が言ってることがおかしいのがわかるはずです。

あくまで、これは「モデル」が使えるだけで、要は同じタイミーさんが来てくれるというだけです。

たとえ同じタイミーさんでも、吉野家の設備と材料で作った牛丼とすき屋の設備と材料で作った牛丼は、別の牛丼になるはずです。

つまり、Gensparkという設備で作ったものと、Claude codeで作ったものは違うものが出来ます。（Skillsやclaude.mdの影響）

ただ、タイミーさんに設備とかがいらない仕事（折り紙で鶴を折るとか）をさせているだけの場合はその違いに気づくことは無理でしょう。

 

冒頭に戻ると、鑑真は「モデル」、船の設備は「ハーネス」。こんな感じです。

みなさんは、鑑真をどうやって、日本に辿り着かせていますか？