AFHL：エージェントが先、人が最後の開発

AFHL（Agent-first, Human-last Engineering）は、当社がアプリを作るときの標準の進め方です。エージェントが計画、実装、検証、自己レビュー、記録までを担います。人は最後に実機で触り、UI と UX を評価します。

人を最後に置く理由

小さな会社で、いちばん足りないのは人の注意です。エージェントは code を読み書きし、build し、自分の変更を見直せます。一方で、触ったときの手触りがよいかどうかは、人が実際に使ってみないと決められません。そこで、人の注意を最後の判断に集めます。当社では、デザイナー出身の代表がこの判断を担っています。

二つのモード

• Iteration（既定）：エージェントは、UI、操作感、応答の速さ、動きの滑らかさを磨くことに力を使います。広い整理や網羅的なテストは後に回し、何を後に回したかを refinement backlog に書き残します。
• Refinement（指示したときだけ）：合意した体験を守ったまま、設計、code、テストを整えます。終わったら Iteration に戻ります。

二つを分けたのは、両方を同時に求めると、どちらも中途半端になるからです。

途中の相談と確認

Human-last は、人が途中にいないという意味ではありません。新しい画面を作る前には、エージェントがプレビューの画像を出し、人が方向を確かめます。

人が試すことを、エージェント自身の確認の代わりにはしません。報告では、「build が通った」と「人が触って確かめた」を分けて書きます。確かめていないことは、確かめていないと書きます。

これまでの運用

2026 年 9 月 19 日から 28 日までの 10 日間で、この進め方で 5 本のアプリを作り始めました。最初に公開を予定している SnapCap は、iPhone のカメラで撮った写真を、1 回の操作で Mac の画面に出すアプリです。

速さ以上に大きかったのは、人の時間の使い方が変わったことです。代表は日々の code review をせず、その分の時間を、触って直す指示を出すことに使っています。

限界

体験の判断は、一人の目に頼っています。人が増えたときに、評価の基準をどう共有するかは、まだ決めていません。後に回したテストと整理が積み上がる危うさもあります。Refinement をいつ入れるかは、今も人が決めています。