LOOP ENGINEERING · 開発編
なぜ
/goal でのループエンジニアリングが
「うまくいかない」のか?
そもそも、ループって何?

ループは大きく三種類

Turn-based
プロンプトを投げるたびに1回。読む→変更→確認→修正して返す。次に進むかは人間が判断。
要するに:毎ターン人が確認しながら進める、ふつうのAIコーディング。
Turn-basedループの図
渡すもの:次の指示
向く作業:探索・単発作業
Goal-based
/goal
「テスト全通過」「Lighthouse 90以上」など完了条件を決め、満たすまで試行(最大回数も指定可)。
要するに:終わりの条件を渡して、達成するまで自動で粘らせる。
Goal-basedループの図
渡すもの:完了条件
向く作業:テスト通過・品質基準の達成
Time-based
/loop/schedule
5分ごと・毎朝など一定間隔で繰り返す。CI確認、レビュー対応、Slack要約、バグ監視など。
要するに:定期的に見に行って、必要な作業を自動で実行。
Time-basedループの図
渡すもの:実行タイミング
向く作業:定期確認・PR監視・Slack要約
そもそも、ループって何?

ループは大きく三種類

Turn-based
プロンプトを投げるたびに1回。読む→変更→確認→修正して返す。次に進むかは人間が判断。
要するに:毎ターン人が確認しながら進める、ふつうのAIコーディング。
Turn-basedループの図
渡すもの:次の指示
向く作業:探索・単発作業
Goal-based
/goal
「テスト全通過」「Lighthouse 90以上」など完了条件を決め、満たすまで試行(最大回数も指定可)。
要するに:終わりの条件を渡して、達成するまで自動で粘らせる。
Goal-basedループの図
渡すもの:完了条件
向く作業:テスト通過・品質基準の達成
Time-based
/loop/schedule
5分ごと・毎朝など一定間隔で繰り返す。CI確認、レビュー対応、Slack要約、バグ監視など。
要するに:定期的に見に行って、必要な作業を自動で実行。
Time-basedループの図
渡すもの:実行タイミング
向く作業:定期確認・PR監視・Slack要約
1

ゴールを伝える

作業指示書(スキル)が整備できていない
済

例えば「UIに何かを追加する」。これ、過去に絶対やったことがある作業。

なのに次も、同じ作業指示を毎回ゼロから直接与えている。

一度きりの指示で終わりにして、スキル(作業指示書)として残していない。

「UIに追加」を毎回繰り返し手順書が散らばる開発者
重要ポイント
スキルは汎用性を持たせるため抽象化する
フローを1つのスキルにまとめない(工程ごとに分ける)
2

計画をチェックする

細かい指示で、計画がないまま進んでいる
済

「ここをこう直して」「次はこれ」と、逐一の細かい指示だけで進めている。

全体の計画(ゴール・手順・完了条件)を先に立てて確認していない。

「自分が知っていること」と「AIが知っていること」を都度確認し合うので、とても効率が悪い。

行き当たりばったりで全体計画がない開発者とAI
重要ポイント
まず調査と計画を行う
これはその後の作業のコンテキストを整備するためでもある
3

危ないことは止める

ガードレールがなく、想定外のことも止まらず進んでしまう
済

CLAUDE.md や権限設定などのガードレールが整っておらず、どこまで自律的にやっていいかの線引きがない。

AIが「良かれと思って」余計な変更・削除・pushまで進めてしまっても、止める仕組みがない。

基準がないので、結局毎回人間が「それ進めていい?」を都度判断する羽目になり、ループが止まる。

AIが分かれ道の先で暴走しかけ、開発者が止めてガードレールを立てているイラスト
重要ポイント
破壊的操作・外部影響のある操作はあらかじめ線引きしておく
CLAUDE.md 等に「やってほしくないことリスト」を育てていく
4

AI自身ができたか確かめる

完了条件が曖昧で、結局人間が毎回目視確認している
済

テストや型チェックはあっても、「機能として正しいか」の合否基準が指示に含まれていない。

完了条件が曖昧なまま「できました」と報告され、結局人間がブラウザを開いて確かめる羽目になる。

検証→自己修正→再試行をAI自身に回させる仕組みがなく、「まだ直ってないよ」の往復が続く。

AIが「できたよ!」と報告し、開発者が画面を見て「間違ってるじゃん」と困惑しているイラスト
重要ポイント
指示に完了条件(テスト通過・スコア基準など)を必ず含める
AI自身が合否判定できる仕組み(テストコマンド・ビルド確認)を用意する
大体もう準備できてませんか?
でも実際にループを回そうとすると
質問攻めにあうし、結果も
思った通りにいかない…
ってなっていませんか?
私の場合うまくいかなかった原因はシンプルでした
私が思っている以上に
私は大量に意思決定をして実装している
そしてその基準を言語化していない
「どうしたか」は残るのに、
「なぜそうしたか」は
残しているつもりで全然残せていない
AIの「普通」の判断は
私には「普通」ではない
普通=バックグラウンドが同じ者同士でしか通じない
一般的な=それ今回も当てはまるの?
髪の赤いおっさんに社会の「普通」を問うな
だから、
似たような状況でも
毎回「判断」を
しなければならない。
AIのループも「判断」が必要なことが残っていると
処理が止まってしまう。
人も同じ。
「自分で決められないこと」があったら、
上司に「判断」を仰ぎますよね?
勝手に決めて行動したら
後で怒られるかもしれませんよね?
で、あなたもAIに指示出して
「何してんねん」って
思うことありますよね?
でもAIも私の判断を待ってたら
手が止まりますよね?
そのたびに私の時間が奪われる。
もうやだ
本当に残すべきは、
「決定したこと」ではなく
「判断の基準」
そしてそれは大小関係なく全て必要
それで、私は何をしたか
全ての意思決定のタイミングで
全ての「基準」を
残すことにした
その基準を残す方法、
それが「ADR」を
残す、ということ。
Architecture Decision Record ― 背景・決定・理由をセットで残す記録
# ADR-023: ボタン色の使い分け基準
## 背景 ボタンの色の判断が画面ごとに毎回発生していた
## 決定 赤=ネガティブ操作(削除・取消)、緑=ポジティブ操作に統一
## 理由 色から操作の意味を即断できるようにするため
でも、ADRでもまだ足りない。
さらに、残すだけでは意味がない。
LOOP ENGINEERING · 開発編

私がやってみていること

「評価」「判断」「解決」言葉いろいろあるけど、「基準」があればその後の「行動」は既に決定している
1

あらゆる場所の意思決定を残す

会議・Slack・コーディング中など、場所を問わず意思決定と決定基準をセットで記録する。

2

ADR化の自動化

Claude Code で行われた意思決定は、自動でADRとして残る仕組みにした。

3

過去の決定を自動検索させる

ループ最初の調査・設計段階で過去の意思決定を自動で検索させ、自己解決させる。

4

解決基準はメタ化する

個別の解決策そのものではなく、次にも使える判断基準として抽象化して残す。

ADRを貯めて、使わせる仕組み

日常の運用に組み込んで、勝手に積み重なるようにする

業務終了時に、SlackやMeetの会議ログもADR化する。

CLAUDE.mdに「迷ったら検索して過去の判断基準に従ってください。それでもわからなかったら聞いてください」と指示して、ADR検索を自動化。

聞かれて答えた内容が、また新しいADRになる。さらなるADRの積み重ねが自然に回り出す。

ADRはOKF+ベクトルDBを利用して、低コストで検索できるようにしている。

会議は「基準」の集まり。
めっちゃ大事。
話し合って
「じゃあこうだから、こうしよう」
こんな大事な意思決定基準を
使わないのはもったいない。
「基準」は価値観に紐づくので
人それぞれ。
経験・価値観・配慮・ポジション・勘
色んな要素で人の行動を決定する
「基準」は違う。
デザイナ、エンジニア、経営者。
みんな違って、みんないい。
あとはプライオリティの問題だけ。
だから、
意思決定の「基準」が
必要。
HOW?
gmemを作った。
とにかく私の全ての「基準」を残す。
手段はなんでもよかった。
コレも答えではない。
MY GMEM WORKFLOW

gmemの仕組み

1
ルートの CLAUDE.md
「全ての私の意思決定(質問に対する応答など)のタイミングでgmemを使用して基準を保存してください」
2
/goal 〜〜〜に関するスライドを作成してください。迷うことがあったらgmemで過去の意思決定の基準を検索してそれに従ってください。それでも不明な点は曖昧にせず質問してください
コレを毎日繰り返すと「私の基準」がどんどんたまります。
GOAL-BASED LOOP

同じ作業が、より「メタ」な指示で通るようになる

よりメタ的な指示を出しても「過去の基準」に基づいて行動することで止まらずに処理できるように
Goal 簡単
「プロフィールの画面にユーザー情報を編集するダイアログを追加して」
Goal 中
「ユーザー情報編集ダイアログを追加して」
Goal 難
「ユーザー情報を編集可能にして」
今の課題

自分で意思決定できないこと

例えばUIデザインなど自分の領域じゃないことは、意思決定の基準に確信がなく裏付けも弱い。

自信のない基準で決めた意思決定は、後から覆ったり、周りを説得できなかったりする。

だからプロダクトを作るためには
「関わる人全ての意思決定の基準」が必要
MY GOAL

私が目指しているもの

/goal ちょっとお金かせげて社会的意義のあるものを作って
MY PLAY

私が遊んでいるもの

プライベートも含めて意思決定の「基準」とは、それは私の全ての経験や知識、価値観、人生観に紐づくもの。だから妻が利用するChatGPTにgmem MCPを紐づけて、妻が相談した時に「私なら何て言うか」を与えるようにしました。Xの15年分の投稿から既に私の口調は真似しているので、かなり私のクローンになってきました。
意思決定の基準を残して
AIがそれに基づいて
行動できる環境を作ろう