はじめに
@t_wadaさんの 「Agentic Coding とは Reconciliation Loop である」 という金言を踏まえて、自分なりに咀嚼し、この前提でよりよくAgentic Codingを実現するための実装パターンを考察した内容となります。
「ここで記載した実装パターンでAgentic Codingが上手くいった！」…というもの ではない ことにご留意ください。あくまで私的な考えをまとめたもので、現在進行形で自分自身で試行錯誤しているものになります。(※なお現時点では良さそうに思えます！！)
対象読者
- 「Agentic Coding」に興味があるエンジニア
- 「Agentic Coding」を推し進めたいが、どう進めていけば良いか悩んでいる方
結論
「Always-Valid Domain Modeling」「Type First」「関数型プログラミング」「Event Sourcing」がAgentic Codingと非常に相性が良いと考えています。
特に「Event Sourcing」は、AIによる自律的な評価・調整の精度と透明性を大きく高めるため、今後の実践において非常に有効なアプローチとなるでしょう！
背景
私が所属している部署のエンジニアは Cursor を日々活用して開発をしています。私自身 Cursor はローンチ初期から活用しており、私の個人的な「推し」です。
しかしながら領域によっては、ドキュメントが整備されていなかったり、長年すごい速度で機能を追加してきた結果ソースコードの秩序がなかったり…、とAIエージェントの機能をフル活用することが難しい部分もあるのが現状です。これを解決するための一つの施策として、どのような実装を良いとするのか、特にAIとの協調性が高い方針を定めよう…！と考えていました。
そんな中目にした、@t_wadaさんの 「Agentic Coding とは Reconciliation Loop である」 という金言を、自分なりに咀嚼しつつ、どんな実装方針が良さそうであるかをまとめています。
「Agentic Coding とは Reconciliation Loop である」とは？
わかりやすかった説明を引用します。
まず、t_wadaさんが言及してる「Agentic Coding」ってのは、エージェント型のAI（ここではClaude Codeとか）が自律的にコードを書いたり修正したりするアプローチのこと。で、その肝となるのが「Reconciliation Loop（調整ループ）」って考え方。これは、簡単に言うと「理想の状態を定義して、そこに現実を近づけるために繰り返し調整する」って仕組みだよ。
イメージとしては、Kubernetesとかのシステムでよく使われる概念に近い。例えば、Kubernetesのコントローラーが「5つのポッドが動いててほしい」っていう理想状態（Desired State）を監視して、実際の状態（Current State）が3つしか動いてなかったら、足りない2つを自動で追加する、みたいな感じ。これをAIコーディングに応用すると、開発者が「こういうコードにしたい」っていうゴールを宣言的に定義して、AIがそのゴールに合うようにコードを自律的に調整していくってわけ。
t_wadaさんが大事って言ってる「理想状態の定義と評価関数の設計」ってのは、このループを回すための鍵。理想状態が曖昧だったり、評価関数（ゴールにどれだけ近いか測る仕組み）が適当だと、AIが的外れなコードを量産しちゃう。逆に、これがしっかりしてると、AIが「ここはバグるから直すね」とか「このロジックもっと効率的にできるよ」って勝手に最適化してくれるんだ
AIが改善のサイクルを回してより良いアウトプットを出せるようにするためには、
- 望ましい状態（理想状態）を宣言的に定義し、
- 現状が望ましい状態と比較してどの程度乖離しているか評価可能な方法を提供する
という2点が重要です。
この2つがあれば、AIは自律的に改善を繰り返し、望ましい状態に近いアウトプットを出すことができるはずです。
この事象を自分なりに図示化したのが以下です。
実際にはAIが開発者が期待する 理想 をそのまま実現することは難しく、
- 望ましい状態（理想状態）を宣言的に定義し、
- 現状が望ましい状態と比較してどの程度乖離しているか評価可能な方法を提供する
の2点によって成果物の精度が変わってきてしまいます。
それで、どうする？
もちろん、理想の状態を定義しよう！…というのはあると思いますが、どのような理想状態の定義や実装方法を選べば、この差分を縮めやすくなるのか？という戦略が非常に重要になると考えます。
結論としては、「Event Sourcing」「Type First」「Always-Valid Domain Modeling」「関数型プログラミング」を活用するのが有効だと考えています。
これらがどのようにReconciliation Loopに寄与するかを表現した図が以下です。
1. Always-Valid Domain Model（AI Createdの品質底上げ）
「間違った状態をそもそも作れないようにする設計」のことです。たとえば「未払いなのに発送済み」など、おかしなデータが絶対に作れないように、ルールをきめた上でルールが徹底されるようにします。 (Always-Valid Domain Modelについては下記参照)
Always-Valid Domain Modelは、AI Createdの段階から不整合な実装を防ぐ基盤となります。「そもそも不整合を作り出すことができない」ドメインモデルを設計することで、AIが生成するコードやデータの品質を根本から担保します。
これにより、AIがどんなに自律的にコードを生成しても、ドメインルールに反する不正な状態が生まれにくくなります。Reconciliation Loopの最初の段階（AI Created）から一定の品質が担保され、以降の改善サイクルの負担が軽減されます。
2. Type First（AI Refined・Defined Idealの質的向上とFBサイクル高速化）
「型」を使って、できること・できないことをはっきりさせる考え方です。プログラムを書く前に「このデータはこういう形・ルールです」と決めておくことで、間違いを早く見つけやすくなります。(Type-Firstについては下記参照)
Type Firstは、AI RefinedやDefined Idealの段階で特に効果を発揮します。型情報を通じて「何ができて何ができないか」を明示的に表現できるため、実装前の段階で期待値や挙動の整理・合意形成が可能となります。
これにより、AIが生成・改善する成果物（AI Refined）と、ドキュメント等で定義された理想状態（Defined Ideal）とのギャップを型レベルで明確にし、フィードバックサイクル（FBサイクル）を高速かつ高精度に回すことができます。
型による制約は初期実装（AI Created）の不整合防止にも寄与しますが、特にAI RefinedとDefined Idealの段階での質的底上げとフィードバックサイクルの高速化に大きく貢献します。
3. 関数型プログラミング（AI Refined以降の改善サイクルの精度・速度向上）
「小さくてシンプルな部品（関数）」を組み合わせてプログラムを作る方法です。一つ一つの部品が独立していて、他に影響を与えにくいので、テストや修正がしやすくなります。(関数型プログラミングについては下記参照)
関数型プログラミングは、AI Refined以降の改善サイクルで、テスト容易性や修正差分の明瞭化をもたらします。副作用のない小さな処理の組み合わせにより、AIは個々の関数単位での改善や検証がしやすくなり、Reconciliation Loopのサイクルを高速かつ高精度に回すことができます。
修正の影響範囲が限定されるため、AIによる自動修正の精度も向上します。
4. Event Sourcing（評価・透明性の向上）
「何が起きたか」を一つ一つ記録していく方法です。たとえば「注文した」「支払いした」「発送した」などの出来事（イベント）を全部残しておくことで、あとから「なぜ今こうなっているのか」を正確にたどることができます。(Event Sourcingについては下記参照)
Event Sourcingは、AI RefinedやDefined Ideal以降の評価・透明性向上に寄与します。イベントを記録し、その評価を行うことで、最終的な状態だけでなく、その過程も評価対象とできます。
AIはイベントの履歴をもとに、どのような経緯で現状に至ったかを把握し、理想状態とのギャップをより精緻に特定できます。これにより、Reconciliation Loopの各サイクルで、より高精度な調整と透明性の高い評価が可能となります。
特に Event Sourcing は「適切に評価することができる」…という観点で非常に有用となり得ると感じています。
Event Sourcingの具体例
たとえば、あるECサイトで「注文（Order）」の状態を管理しているとします。
状態スナップショット方式では、次のようなデータだけが保存されます。
{
"orderId": "123",
"status": "Shipped",
"user": "Alice"
}
この情報だけでは、「なぜこの注文がShipped（発送済み）になったのか」「本当に正しい手順を踏んで発送されたのか」は分かりません。たとえば、「支払いが完了していないのに発送された」などの問題があっても、状態だけでは原因を特定できません。
Event Sourcingの考え方
Event Sourcingでは、「どんな出来事（イベント）が起きたか」を時系列で記録します。
同じ注文の例で、次のようなイベントが記録されます。
[
{ "type": "OrderPlaced", "orderId": "123", "user": "Alice", "timestamp": "2024-06-01T10:00:00Z" },
{ "type": "PaymentConfirmed", "orderId": "123", "timestamp": "2024-06-01T10:05:00Z" },
{ "type": "OrderShipped", "orderId": "123", "timestamp": "2024-06-01T12:00:00Z" }
]
このように「注文が作られた」「支払いが確認された」「発送された」という**経緯（履歴）**がすべて残ります。
差分検証の具体例
AIが実装を検証する場合、
- 理想的なイベントの流れ（例：注文→支払い→発送）
- 実際に記録されたイベントの流れ
を比較します。
もし、実際のイベントが次のようになっていたらどうでしょう？
[
{ "type": "OrderPlaced", "orderId": "123", "user": "Alice", "timestamp": "2024-06-01T10:00:00Z" },
{ "type": "OrderShipped", "orderId": "123", "timestamp": "2024-06-01T12:00:00Z" }
]
この場合、「PaymentConfirmed（支払い確認）」イベントが抜けていることが一目で分かります。
AIは「支払いが確認されていないのに発送されている」という業務上の問題を正確に指摘することが可能となります。
まとめ
「Always-Valid Domain Modeling」「Type First」「関数型プログラミング」「Event Sourcing」は、Agentic CodingのReconciliation Loopの各段階で異なる役割を果たしながら、AIによる自律的な改善サイクルの質と速度を底上げします。
- Always-Valid Domain Model：AI Createdの品質底上げ
- Type First：AI Refined・Defined Idealの質的向上とフィードバックサイクル高速化
- 関数型：AI Refined以降の改善サイクルの精度・速度向上
- Event Sourcing：評価・透明性の向上
特にEvent Sourcingは、AIによる自律的な評価・調整の精度と透明性を大きく高めると考えています。
各実装パターンを具体的にどう落とし込んでいくか、実際に運用してみてどうだったか…は機会があれば、別記事でまとめていこうと思います！
またTypeScriptでの実装例について、「TSKaigi 2025 After Night 〜セッションおかわりの会！〜」で触れたいと思っています！！よければ参加ください〜
Discussion