Human-in-the-loop と Loop Engineering を組み合わせる Memolog の AI 開発
Memolog の開発では、最初から詳細な仕様と完了条件を決めて、その通りに GitHub Copilot（以下、Copilot）へ実装させているわけではありません。
「こんな機能があるとよさそう」「この体験をもう少し良くしたい」と会話を始め、まず 80 点くらいの形を作ってもらいます。実際に触り、違えば直します。ただし、想像とは違っても、できたものの方が良ければ採用します。
これまで自分は、この反復全体を Loop Engineering と捉えていました。しかし、Addy Osmani による Loop Engineering の説明や、その内容を日本語で紹介した「入門から実践 -「ループエンジニアリング」」と照らすと、それでは人と AI が対話するループと、AI を自律的に動かす仕組みを混同していました。
この記事ではあらためて、Memolog の進め方を 外側の Human-in-the-loop と、内側の Loop Engineering という二重ループとして整理します。
目次
- 先に結論
- 3 つの言葉を分けて考える
- Memolog の二重ループ
- 外側で正解を発見し、内側で正解へ近づく
- 最初から 100 点を定義しない
- Memolog で回している 6 つのループ
- 1on1 を本線にしている理由
- ブログ執筆にもループがある
- 観測可能なチェックポイントをどう置くか
- ループを安全に続けるための境界
- まとめ
先に結論
Memolog の開発は、1 種類のループだけで進んでいるわけではありません。
- 外側は Human-in-the-loop：人と AI が対話し、試作品を見ながら、作るものと判断基準を発見する
- 内側は Loop Engineering：採用したゴールへ向けて、AI が実装、テスト、修正、再テストを自律的に繰り返す
- 重要な境界では人が判断する：セキュリティ、費用、データ削除、公開などは AI だけで決めない
Memolog では、次の流れを基本にしています。
人と AI が曖昧なアイデアを会話する
↓
AI が 80 点くらいの形にする
↓
実際に見たり触ったりする
↓
人が採用、修正、見送りを判断する
↓
採用したゴールまで AI が実装と検証を繰り返す
↓
人が確認して公開し、観測を次の改善へ戻すこの進め方では、完成条件を最初からすべて固定しません。セキュリティ、データ保護、既存機能の維持など、外せない条件は先に決めます。一方で、UI、文章、操作感、見せ方は、試作品を見てから決める余地を残します。
この整理では、Human-in-the-loop と Loop Engineering は競合する方法ではありません。人が目的と責任を持ち、その内側で AI が検証可能な作業を自走するという関係です。
3 つの言葉を分けて考える
今回の見直しでは、Human-in-the-loop、Human-on-the-loop、Loop Engineering を次のように分けます。これらに一つの統一規格があるという意味ではなく、Memolog の実践を説明するための整理です。
| 言葉 | 人の関わり方 | Memolog での例 |
|---|---|---|
| Human-in-the-loop | 人がワークフローの途中に入り、入力、評価、承認を行う | 試作品を触り、採用、修正、見送りを決める |
| Human-on-the-loop | AI の自律実行を人が監督し、必要なときに介入する | 自動チェックや CI の結果を監視し、例外時に止める |
| Loop Engineering | 人が逐次指示する代わりに、AI が目標へ向けて発見、実行、検証、再試行する仕組みを設計する | 実装後にテストを実行し、失敗原因を直して再テストする |
Memolog の開発全体を Human-on-the-loop と呼ばないのは、人が例外時だけ介入する監督者ではないからです。試作品を見て考えを変え、好みを言葉にし、次に作るものを決めるところまで人がループへ参加します。一方、内側の実装ループが動いている間は、人が逐次指示せず結果を監督するため、Human-on-the-loop に近い場面もあります。
Microsoft Agent Framework の公式ドキュメントでも、エージェントが操作前に人の承認を求め、承認または拒否を受けて処理を続ける形を Human-in-the-loop と説明しています。
一方、Addy Osmani は Loop Engineering を、人がエージェントへ逐次プロンプトする役割から離れ、その代わりにエージェントを動かすシステムを設計することだと説明しています。目的を与えた後、AI が完了条件を満たすまで反復することが中心です。
この定義に従うと、人と Copilot の会話を繰り返すだけでは Loop Engineering とは言えません。Memolog では、会話による探索を Human-in-the-loop、その中で実装と検証を自走させる仕組みを Loop Engineering と捉えます。
Memolog の二重ループ
外側と内側では、ループを回す主体が違います。
| ループ | 主体 | ゴール | 停止条件 |
|---|---|---|---|
| 外側の発見ループ | 人と AI | 欲しいものと判断基準を見つける | 人が採用、修正、見送りを決める |
| 内側の実装ループ | AI と自動チェック | 採用したゴールを実装する | テストなどの完了条件を満たす、または停止条件に達する |
外側では、人の違和感や好みが重要です。内側では、ビルド、テスト、Lint、Playwright、API 応答など、機械が観測できる条件が重要です。
すべてを自動化することが目的ではありません。まだ正解が分からない仕事は人と探索し、正解を決めた後の反復可能な仕事を AI と仕組みに渡すことが目的です。
外側で正解を発見し、内側で正解へ近づく
外側の発見ループ
まだ欲しいものが明確ではない段階で回すループです。
会話 → 試作 → 体験 → 違和感や好みを言葉にする → 再試作ここでは、最初の要望への一致率だけで評価しません。「思っていたものとは違うけれど、こちらの方が良い」という結果も成功です。成果物が人の考えを更新する材料になります。
これは Human-in-the-loop です。人は最後の承認だけでなく、成果物を材料に考え、次の方向を決める参加者です。
内側の実装・検証ループ
外側で方向を決めた後は、Copilot が実装と検証を進めます。
実装 → テスト → 失敗原因を読む → 修正 → 再テストこの間、人がテスト失敗のたびに次の指示を書く必要はありません。AI が結果を読み、原因を特定し、修正して再実行します。全チェックの成功、試行回数の上限、同じ失敗の繰り返しなど、観測可能な停止条件も先に置きます。
ここが Memolog における Loop Engineering です。探索中のすべてを固定するのではなく、外側では柔らかく発見し、採用後は内側のループで必要な部分だけ固くすることを意識しています。
最初から 100 点を定義しない
自分は、実装前に詳細な完了条件を作るのが得意ではありません。また、できたものを見てから考えが変わることもよくあります。
そのため、最初は 80 点くらい合えばよいと考えています。
ただし、すべてを曖昧にするわけではありません。条件を次の 2 種類に分けます。
| 条件 | 先に決めること |
|---|---|
| 外せない条件 | セキュリティ、データ破壊の防止、既存機能、費用の上限、公開の承認 |
| 探索できる条件 | UI、文章、操作感、見せ方、細かな仕様 |
たとえば、モーダルを追加するときに「使いやすくて自然なモーダル」を最初から厳密に定義するのは難しいです。一方で、開閉できること、モバイルで崩れないこと、閉じた後に操作を続けられることは確認できます。
まず動くものを作り、実際に触って好みや違和感を返します。そこで採用した操作を Playwright のテストへ残せば、探索の自由と回帰防止を両立できます。
Memolog で回している 6 つのループ
実際の作業を振り返ると、Memolog では複数のループがつながっています。
| ループ | 位置づけ | 目的 | Memolog での例 |
|---|---|---|---|
| 発見 | 外側 | 欲しいものを見つける | UI や記事の方向を会話と試作から決める |
| 実装 | 内側 | アイデアを動く形にする | Copilot がコード、設定、記事を変更する |
| 検証 | 内側 | 壊れていないか確かめる | ビルド、Playwright、API、構造化データを確認する |
| 品質 | 外側と内側 | 採用したものをより良くする | 差分レビュー、モバイル確認、英語の独立レビューを行う |
| デリバリー | 内側から人の判断へ | 本番へ届ける | GitHub Actions、Azure へのデプロイ、本番画面を確認する |
| 運用 | 次の外側へ | 公開後から学ぶ | Application Insights、GitHub Issue、実際の利用から改善する |
これらは必ず一方向に進むわけではありません。検証で問題が見つかれば実装へ戻り、本番を見て新しいアイデアが生まれれば発見へ戻ります。
以前の記事「Memolog を作る上で、自分と GitHub Copilot はどう役割分担したか」では、調査、設計、実装、テスト、本番確認、記録を Copilot と往復してきた経緯を紹介しました。今回の二重ループは、その役割分担のどこに人が入り、どこを AI が自走するかを捉え直したものです。
1on1 を本線にしている理由
1on1 と Loop Engineering は対立しません。外側の発見ループは 1on1 で進め、ゴールが決まった後の内側だけを Copilot に自走させることができます。また、Loop Engineering に複数の AI エージェントが必須というわけでもありません。重要なのはエージェントの人数ではなく、AI が完了条件まで反復できる仕組みです。
Memolog は 1 人で管理している比較的小規模なリポジトリです。普段の作業は、自分と 1 つの Copilot セッションによる 1on1 を中心にしています。
- 会話の流れと直前の判断を保ちやすい
- UI を見た感想や、記事で伝えたいニュアンスを返しやすい
- Web、API、Azure、CI をまたぐ変更でも、一つの文脈で追いやすい
- 誰が最終判断するのかが曖昧になりにくい
小規模なリポジトリでは、別々の作業でも同じページ、共通コンポーネント、ワークフローに変更が集まりやすくなります。複数のエージェントを並行して動かすと、文脈の引き継ぎや判断の衝突に加え、差分の比較、重複した変更の選別、マージ順の調整が必要です。Memolog では、この統合コストが並列化の効果を上回りやすいことも、1on1 を本線にしている理由です。
一方で、自分では品質を判断しにくい英訳には、独立したサブエージェントを使っています。
英語文書のレビューでは、「自分の文章らしさ」を残しながら、翻訳調の表現を減らすために、次の 6 点を意識するとよいというフィードバックも得ました。
organizeを便利な言葉として多用しない- 文頭の
Soを繰り返さない - 名詞化された表現を、できるだけ動詞へ戻す
- 日本語の「〜することができる」に引っ張られた不要な
canを減らす - 長い一文は、意味の区切りで 2 文に分ける
- 日本語の語順を保つのではなく、英語で自然な順序に因果関係を組み直す
これは単語を機械的に置き換えるルールではありません。主張や語り口を残したまま、英語の読者が意味を追いやすい構造へ書き直すための観点です。
この仕組みは「日本語を自然な英文へ翻訳する Memolog の取り組み」で詳しく紹介しています。
普段は自分と Copilot の 1on1 で進め、独立した視点が必要な場所だけサブエージェントを加えます。サブエージェントは最終決定者ではなく、自分とメインの Copilot だけでは得にくい判断材料を提供する役割です。
ブログ執筆にもループがある
Human-in-the-loop による探索は、コードだけが対象ではありません。この記事も、最初に全構成を決めてから書き始めたわけではありません。
この記事では、まずチャットで AI との開発の進め方を話し、質問と回答を繰り返しました。その過程で、次の考えが言葉になりました。
- 最初から完了条件を固定するより、動くものを見て判断したい
- 想像と違っても、できたものの方が良ければ受け入れたい
- 80 点くらいの試作を早く見たい
- 基本は 1on1 で進めたい
- 自分で判断できない英訳は、独立した担当へ委任したい
- チェックポイントを品質検査だけでなく、次の判断材料として使いたい
記事を書くときの流れも、外側と内側に分けられます。
| 位置づけ | ループ | やること |
|---|---|---|
| 外側 | 発掘 | 質問と回答で、経験、感情、主張を取り出す |
| 外側 | 構成 | 見出しと順番を提案し、足す、削る、並べ替える |
| 外側 | 執筆 | 下書きを読み、自分らしくない箇所や強調したい点を直す |
| 内側 | 事実確認 | 日付、製品名、リンク、実際の実装と照合する |
| 外側 | 読者確認 | 初見の読者に前提と結論が伝わるか見直す |
| 内側から人の判断へ | 公開 | ビルド、JA / EN、表示、リンク、メタデータを確認する |
自分の中に完成した答えがあり、AI がそれを書き写しているのではありません。対話と下書きを使って、自分が何を伝えたいのかも発見しています。
観測可能なチェックポイントをどう置くか
チェックポイントの役割も、外側と内側で異なります。外側では、何が見えたら人が次の判断をできるかを考えます。内側では、AI が次の反復へ進む条件と、止まる条件は何かを決めます。
作業を始めるとき、次の 4 つを Copilot と一緒に考えます。
- 途中で何を見れば、方向を修正できるか
- 壊れたとき、何を見れば気づけるか
- 自動チェックで繰り返し確認できる部分はどこか
- 最後に自分が触って判断すべき部分はどこか
Memolog では、チェックポイントを次のように置くことが多いです。
| タイミング | 観測するもの | 確認方法 |
|---|---|---|
| 試作後 | 画面、文章、構成、操作感 | 自分で見て触る |
| 実装後 | ビルド、テスト、Lint、Playwright、API 応答 | 自動チェックを実行し、Copilot が結果を読む |
| レビュー時 | 差分、回帰、セキュリティ、英語の自然さ | 自分と Copilot で確認し、英訳は独立したサブエージェントがレビューする |
| デプロイ後 | GitHub Actions、本番 URL、代表的な操作 | Copilot が状態を確認し、自分も本番を触る |
| 運用中 | テレメトリ、Issue、利用時の違和感 | 自動収集した情報を Copilot と自分で読む |
ここでいう自動チェックは、ビルド、テスト、Lint、Playwright、CI、テレメトリなど、人が毎回同じ手順を繰り返さなくても結果を返せる仕組みです。
独立したサブエージェントは、自動チェックとは別です。Memolog では主に、自分では自然さを判断しにくい英訳の編集とレビューを担当します。サブエージェントの指摘は判断材料であり、記事へ反映して公開するかは自分が決めます。
外側の観測結果は、合格と不合格だけではありません。
- 想像通りなので採用する
- 違うので修正する
- 想像と違うが、こちらの方が良いので採用する
- 判断材料が足りないので、別案や追加の観測を見る
どれも次の行動を決められるため、有効なチェックポイントです。
ループを安全に続けるための境界
反復を速くしても、AI にすべての判断と権限を渡すわけではありません。Memolog では、次の境界を残しています。
- リポジトリや Azure を変更する前に GitHub Issue を用意する
- セキュリティ、費用、データ削除、公開に関わる判断は人が持つ
- 実装後は対象テストから始め、必要に応じて全体テストへ広げる
- GitHub Actions と本番状態を確認し、結果を Issue へ残す
- 同じ修正が繰り返し失敗する場合は、前提や設計へ戻る
- 公開する日本語と英語は、独立レビューと同期チェックを通す
Issue は、最初から仕様を完全に固定するためだけのものではありません。何を試したのか、どこで考えが変わったのか、何を確認して採用したのかを残す場所でもあります。
Loop Engineering の自律性は、無制限に動かすことではありません。どこで自動的に止まり、どこで Human-in-the-loop へ制御を返すかまで含めて設計することが重要です。
まとめ
Memolog の AI 開発は、Human-in-the-loop と Loop Engineering の二重ループで進みます。
- 外側では、人と AI が 1on1 で 80 点くらいの試作を作り、欲しいものを発見する
- 内側では、AI が採用したゴールへ向けて実装、テスト、修正を繰り返す
- 外側のチェックポイントは、人が次を判断するために置く
- 内側のチェックポイントは、AI が続行、完了、停止を判断するために置く
- セキュリティ、費用、データ削除、公開などの責任は人が持つ
- 自分で品質を判断しにくい領域には、独立したサブエージェントを加える
- 公開後の結果を、次の外側の発見ループへ戻す
自分が最初から正解を定義できなくても、Human-in-the-loop で成果物を見ながら正解を発見できます。正解を決めた後は、Loop Engineering によって AI が実装と検証を繰り返せます。
人がずっと手を動かすわけでも、AI にすべてを任せるわけでもありません。人が正解と責任を持ち、AI が決めた正解へ近づく反復を担う。それが、今の Memolog に合っている二重ループです。