AIチームが迷わないために、GitHubに「decision」と「rule」を残す方法
このnoteでわかること
AIをチームとして運用すると、できることは一気に増えます。
でも判断基準が曖昧なままだと、AIは少しずつ違う方向へ進んでしまいます。
このnoteでは、AIチームが迷わないために、私がGitHubへ残している decision と rule について書きます。
具体例として、Claude Codeで `/cut` コマンドを作った時の判断記録や、Brand Harnessへの応用例も紹介します。
テーマは、
AIに何をさせるかではなく、AIが迷った時にどこへ戻るか。
AIを使って仕事をする時、私は最初から「ひとつのAIに何でも頼む」よりも、
AIをチーム化して使うことを考えてきました。
文章を整えるAI。
構成を見るAI。
コードを書くAI。
検証するAI。
方針を見直すAI。
出荷前にチェックするAI。
それぞれのAIに役割を持たせて、
人間である私がすべてを抱え込むのではなく、
AIたちと分担しながら仕事を進める。
私にとってAI活用は、
「AIに全部やってもらうこと」ではありません。
むしろ、
自分の判断軸を持ったまま、AIチームと共創すること
に近いです。
AIをある程度使っている人なら、
AIが文章を書けることも、コードを書けることも、整理や比較ができることも、もう知っていると思います。
でも、AIチームとして運用しようとすると、
本当に難しくなるのはそこではありません。
難しいのは、
判断基準をどう共有し、どう残し、どう次の作業に引き継ぐか
です。
AIは案を出せます。
実装もできます。
修正もできます。
何度も試すこともできます。
でも、その案の中から何を選ぶのか。
どこまで自動化するのか。
何を「よい状態」とするのか。
どこで止めるのか。
どこから人間が確認するのか。
何を、あえてやらないのか。
そこは、AIが最初から持っているものではありません。
特にAIエージェントやClaude Codeのようなツールを使っていると、
作って、試して、修正して、また試す、というループが自然に発生します。
このループは強力です。
でも同時に、判断軸がないままループすると、
AIは一生懸命に動いているのに、少しずつ違う方向へ進んでしまうことがあります。
ループするAIほど、判断軸がないと迷走する。
だから私は、AIチームと一緒に仕事をするために、GitHubに decision と rule を残すようにしています。
これは、AIに毎回細かく指示を出すためではありません。
AIが迷った時に戻ってこられる場所を作るため。
未来の自分が、なぜそう判断したのかを思い出せるようにするため。
そして、AIとの共創を「その場限りのチャット」で終わらせないためです。
AIチーム運用で難しいのは、実行よりも判断の継承
AIをチーム化して使うと、作業はかなり進めやすくなります。
ただ、そのぶん
「誰が何を基準に判断するのか」
を曖昧にしたままだと、途中でズレが出ます。
たとえば、Claude Codeで実装を進めていると、
「コードを書いてもらうこと」自体よりも、
その前後にある判断の方が難しいと感じます。
どこまで自動化するのか。
初期値をどうするのか。
エラー時に止めるのか、警告にするのか。
人間の確認をどこに残すのか。
速さと品質のどちらを優先するのか。
複雑な実装を今やるのか、後回しにするのか。
こういう判断は、AIが勝手に決めてくれるものではありません。
AIは実装できます。
でも、私が何を大事にしているかまでは、最初から知っているわけではありません。
たとえば動画編集の補助ツールを作る時でも、
ただ「速く処理できる」だけでは不十分です。
私にとっては、
視聴者が疲れないこと
話者の息継ぎが消えすぎないこと
意味の区切りが不自然にならないこと
編集者が最後に確認できる余地を残すこと
自動化しすぎて、現場の感覚を壊さないこと
こういう判断基準が大事です。
でも、AIは最初からその感覚を持っているわけではありません。
こちらが何を「自然」と感じるのか。
どこまで詰めると「速い」ではなく「せわしない」になるのか。
どこまで自動化すると便利で、どこから危ないのか。
それは、作りながら人間側が言葉にしていく必要があります。
だから私は、判断基準をその場のチャットだけに残さず、
GitHubに decision と rule として残すようにしています。
GitHubというと、コードを置く場所というイメージが強いかもしれません。
でも私は、コードだけではなく、判断の記録や制作方針を置く場所としても使っています。
たとえば、こんなものを置いています。
基本方針
decision
rule
制作メモ
出荷前チェック
AIチームの役割
プロジェクトごとの判断履歴
GitHubに残すことで、AIにも、人間にも、
「前にどう決めたのか」
「何を大事にしていたのか」
「次も迷った時にどこへ戻ればいいのか」
が見えるようになります。
decision は「なぜそう決めたか」を残す記録
私が残しているもののひとつが、decision です。
decision は、その名の通り「決定」の記録です。
ただし、単に
「A案にしました」
と書くだけではありません。
私が残したいのは、なぜそう決めたのかです。
AIとコーディングしていると、いろいろな判断が発生します。
この仕様を採用するか
この挙動を自動化するか
オプションとして残すか
初期値をどうするか
複雑な実装を今やるか、後回しにするか
人間の確認を必須にするか
エラー時に止めるか、警告だけ出すか
こういう判断は、コードの中には残りにくいです。
コードには「結果」は残ります。
でも、なぜその形にしたのかは、意識して残さないと消えていきます。
そして理由が消えると、次にAIへ修正を頼む時に、また同じ説明をすることになります。
あるいは、AIが前の判断を知らないまま、
一見きれいだけれど、こちらの意図とはズレた修正をしてしまうことがあります。
だから私は、判断が発生した時に、できるだけその理由も一緒に残すようにしています。
decision には、たとえばこんな項目を入れます。
# 決めたこと
# 採用理由
# 比較した案
# 今回見送った案
# 次回に残すこと大事なのは、正解をきれいにまとめることではありません。
むしろ、
なぜ迷ったのか。
何と比較したのか。
なぜ今回は採用しなかったのか。
次に同じような場面が来たら、何を参考にすればいいのか。
そこを残しておくことです。
具体例：Claude Codeで /cut コマンドを作った時
たとえば私は、動画編集の作業を楽にするために、Claude Codeを使って /cut というコマンドを作りました。
これは、文字起こしやテロップ作業の前段階で、
読みやすさや息継ぎの感覚を見ながら、カットや分割の判断を補助するためのものです。
この時に難しかったのは、
「コードを書いてもらうこと」そのものではありませんでした。
むしろ難しかったのは、
何をよいカットとするか
どこまで自動化して、どこから人間が判断するか
を決めることでした。
たとえば、こんな判断が必要になります。
読点でどのくらい息継ぎを感じるか
文頭にどれくらい余白を持たせるか
テンポを速くしすぎないか
速度調整をどこまで自動化するか
自動カットの結果をそのまま使うのか、人間が確認する前提にするのか
編集者ごとの好みをどこまで反映するか
一度決めた基準を、次の修正でも再利用できるようにするか
Claude Codeは、コードを書くことができます。
でも、私がどんな編集テンポを「自然」と感じるのかまでは、最初から知っているわけではありません。
たとえば、文頭の余白をどうするか。
自動処理としては、できるだけ詰めた方がテンポよく見えるかもしれません。
でも、実際に動画として見た時に、話し出しが詰まりすぎると、視聴者が少し疲れます。
テンポは大事です。
でも、呼吸も大事です。
この時、私は /cut の文頭パディングについて、こんな decision を残します。
# 決めたこと
/cut の文頭パディングを 1f から 5f に変更する。
# 採用理由
1f だと、話し出しが詰まって聞こえる場面があった。
5f にすると、ジェットカットのテンポは保ちながら、息継ぎの余白が残る。
# 比較した案
- 1f のままにする
- 3f にする
- 5f にする
- 話者や案件ごとに可変にする
# 今回見送った案
話者ごとの完全自動調整は、初期実装では複雑になりすぎるため見送る。
# 次回に残すこと
案件ごとのテンポ差を反映できるように、--speed オプションや設定ファイル化を検討する。この記録があると、あとからAIに修正を頼む時に、
「なぜ5fにしたのか」
「何を守るための変更だったのか」
「次にどこを改善すればいいのか」
が共有しやすくなります。
AIにコードを書いてもらう時、
つい「動くかどうか」だけを見てしまいがちです。
もちろん、動くことは大事です。
でも、現場で使える道具にするには、それだけでは足りません。
なぜその初期値なのか。
なぜその挙動なのか。
なぜそこは自動化しすぎないのか。
なぜ最後に人間の確認を残すのか。
その判断を残すことで、AIとのコーディングは、単なる一回の実装ではなく、
育てていける道具づくりになります。
rule は「次も迷わないための約束」を残す記録
decision が「その時の判断」だとしたら、
rule は「これからも使う判断基準」です。
一度だけの判断ではなく、今後も繰り返し使いたいもの。
迷った時に戻ってくるための約束。
AIにも、自分にも共有しておきたい方針。
それを rule として残しています。
rule には、たとえばこんな項目を入れます。
# ルール
# 意図
# 適用範囲
# 迷った時の扱い/cut の例でいうと、こんな rule になります。
# ルール
自動カットでは、速さよりも聞きやすさを優先する。
# 意図
テンポを上げることは大事だが、話者の息継ぎや意味の区切りを消しすぎると、視聴者が疲れるため。
# 適用範囲
/cut コマンド、テロップ分割、読点・句点ベースのカット補助。
# 迷った時の扱い
判断に迷ったら、短く詰めるよりも、少し余白を残す。これは、単なる操作マニュアルではありません。
私が編集で何を大事にしているか。
AIにどんな判断をしてほしいか。
どこで人間の感覚を残したいか。
それを残すためのものです。
この rule があると、次にClaude Codeへ修正を頼む時も、AIが単に「動くコード」を作るだけでなく、
私が大事にしている編集感覚に戻りやすくなります。
たとえばAIが、処理効率やテンポを優先して、さらに短く詰める提案をしたとします。
その時に rule があれば、
「このツールでは速さより聞きやすさを優先する」
「意味の区切りや息継ぎを消しすぎない」
「迷ったら少し余白を残す」
という基準に戻れます。
rule は、AIを縛るためのものではありません。
むしろ、AIが安心して動くためのものです。
そして、人間である私自身も、迷った時に戻れる場所になります。
decision と rule を使うと、AIとの修正ループが安定する
AIエージェントやClaude Codeのようなツールを使っていると、
作って、試して、直して、また試す、という流れになります。
このループ自体は、とても強力です。
でも、ループするたびに判断基準が変わってしまうと、
ツールはどんどん違う方向へ育ってしまいます。
たとえば /cut なら、
最初は「聞きやすさ」を大事にしていたはずなのに、
途中から「もっと短く」「もっと速く」「もっと自動で」と進めすぎてしまうかもしれません。
もちろん、速さや自動化は大事です。
でも、それが最優先ではない場合もあります。
だから、ループの途中で戻る場所が必要になります。
私の場合は、その戻る場所が decision と rule です。
実際の使い方は、だいたいこの流れです。
まず基本方針を置く
Claude Codeで実装する
実際に使ってみる
違和感が出たら修正する
その判断を decision に残す
繰り返し使う基準は rule に昇格させる
次の修正では、その decision / rule を参照する
最初から完璧なルール集を作ろうとはしていません。
むしろ、作業しながら増えていきます。
実際に使ってみて、
「ここはもう少し余白がほしい」
「この自動化は便利だけど、確認なしだと危ない」
「この初期値は案件によって変えたい」
と感じたら、それを判断として残します。
その場で直して終わりにしない。
なぜそう直したのか。
次に同じ場面が来たらどうするのか。
これは一回限りの判断なのか、今後も使うルールなのか。
そこまで残しておくことで、AIとの作業が積み上がっていきます。
一回一回のやり取りが、未来の判断材料になる。
それが、私にとって大きな意味があります。
AIチームに丸投げするのではなく、役割を分ける
私は、AIに全部丸投げしたいわけではありません。
むしろ、AIと一緒に仕事をするほど、
「自分が何を担当するのか」
をはっきりさせる必要があると感じています。
私の中では、AIチームにはそれぞれ役割があります。
人間：ビジョン・最終判断
統括AI：文脈整理・進行
実装AI：検証・実装・改修
観測AI：リサーチ・兆しの発見
監査AI：品質・リスク・抜け漏れ確認
接続AI：差分整理・実装導線・情報整理
これは、私がAIとの役割分担を理解しやすくするためのチーム設計です。
AIは、それぞれ得意なことがあります。
文章を整えるのが得意なAI。
構造を見つけるのが得意なAI。
ミスや矛盾を見つけるのが得意なAI。
コードやファイル操作に強いAI。
でも、どの案を採用するか。
どこまで自動化するか。
何を安全とするか。
どの違和感を優先して直すか。
最後にどの状態を「完成」とするか。
そこは、人間である私が持つ部分です。
AIに任せる部分が増えるほど、人間の仕事は「作ること」から判断軸を持つことに寄っていく。
だから私は、AIに作業を投げるだけではなく、
AIチームが迷った時に戻れる判断軸を残しておきたいと思っています。
Brand Harnessにも同じ考え方を使える
この考え方は、コーディングだけに使うものではありません。
たとえば私は、Brand Harnessのような、
ブランド表現の判断軸を扱う仕組みにも、同じ考え方を使えると思っています。
Brand Harness は、簡単に言うと、
AIがブランドらしさを判断するための土台です。
ブランドの色。
言葉のトーン。
避けたい表現。
読者に残したい印象。
強く売るのか、静かに信頼されるのか。
親しみやすさを優先するのか、専門性を前に出すのか。
こういうものを、その場限りの感覚で毎回伝えるのではなく、
AIが参照できる形にしておく。
この時も、難しいのは「AIに文章を出させること」ではありません。
難しいのは、
どの言葉をブランドらしいとするのか
どの表現を避けるのか
色やトーンの判断をどう残すのか
AIにどこまで提案させて、どこから人間が決めるのか
毎回ブレないために、何を rule として残すのか
です。
たとえば decision には、こう残せます。
# 決めたこと
ブランド表現では「強く売る」よりも「静かに信頼される」トーンを優先する。
# 採用理由
対象読者に対して、煽りや圧の強いコピーは合わない。
長く残る仕事の土台として、落ち着いた言葉を使いたい。
# 比較した案
- セールス感の強い表現
- 具体的な成果を前面に出す表現
- 静かな信頼感を優先する表現
# 今回見送った案
短期的なクリックを狙う強い煽り表現。
# 次回に残すこと
LPやSNS投稿でも同じトーンを維持する。rule には、こう残せます。
# ルール
ブランド表現では、煽りよりも信頼感を優先する。
# 意図
一時的な反応より、長く続く関係性を大事にするため。
# 適用範囲
LP、SNS投稿、電子書籍紹介文、サービス説明文。
# 迷った時の扱い
クリックされそうでも、圧が強い表現は避ける。このように、decision と rule は、
コードにも、ブランドにも、文章にも使えます。
共通しているのは、
判断をその場で消さず、次に使える形で残すということです。
これから始める人は、まずこの3つだけでいい
ここまで読むと、少し大がかりに見えるかもしれません。
でも、最初から完璧な仕組みを作る必要はありません。
これから始めるなら、まずはこの3つだけで十分だと思います。
00_基本方針.md
decision/
rule/00_基本方針.md
ここには、プロジェクト全体で大事にしたいことを書きます。
たとえば、コーディング支援ツールならこうです。
# このプロジェクトで大事にすること
- 動くことだけでなく、現場で使いやすいことを重視する
- 自動化しすぎず、人間が確認できる余地を残す
- 速さよりも、最終的な品質を優先する
- 迷ったら、使う人の負担が減る方向を選ぶ
- 判断の理由を残すブランドや文章制作なら、こうです。
# このプロジェクトで大事にすること
- 読者を急かさない
- 体温のある言葉を残す
- AIは共創相手として扱う
- 最終判断は人間が持つ
- 成果物だけでなく、判断の記録も残す完璧な文章でなくて大丈夫です。
自分が迷った時に戻れる言葉があれば、それで十分です。
decision/
ここには、判断の履歴を残します。
テンプレートは、これくらいで十分です。
# 決めたこと
# 採用理由
# 比較した案
# 今回見送った案
# 次回に残すこと判断が発生したら、毎回きれいに書かなくてもいいです。
箇条書きでいい。
メモでいい。
あとから読み返して、なぜそうしたのかがわかれば十分です。
rule/
ここには、繰り返し使う判断基準を残します。
# ルール
# 意図
# 適用範囲
# 迷った時の扱いたとえば、コーディングならこうです。
# ルール
自動化しすぎず、人間が確認できる余地を残す。
# 意図
AIの処理結果をそのまま通すと、現場の細かい違和感を拾えないことがあるため。
# 適用範囲
編集補助ツール、ファイル変換、文章整形、出力前チェック。
# 迷った時の扱い
完全自動化よりも、確認ステップを残す。ブランド表現ならこうです。
# ルール
煽りよりも信頼感を優先する。
# 意図
一時的な反応より、長く続く関係性を大事にするため。
# 適用範囲
LP、SNS投稿、電子書籍紹介文、サービス説明文。
# 迷った時の扱い
クリックされそうでも、圧が強い表現は避ける。こういう rule があるだけで、AIに相談する時の軸がかなり安定します。
AIに任せるほど、人間の責任は消えない
AIに任せられることは、これからもっと増えていくと思います。
だからこそ、人間の役割がなくなるのではなく、
人間の役割が変わっていくのだと思います。
何を作るのか。
誰に届けるのか。
どこまで任せるのか。
何を自分で引き受けるのか。
どの判断に責任を持つのか。
そこは、AIに丸投げできません。
AIはとても心強い相棒です。
でも、AIが動く方向を決めるのは、人間側の判断軸です。
だから私は、AIに任せる範囲が広がるほど、
自分の判断基準を外に出しておくことが大事だと感じています。
decision と rule は、AIのためだけのものではありません。
未来の自分のためでもあります。
「あの時、なぜこう決めたんだっけ？」
「次もこの方向でいいんだっけ？」
「この実装は、自分の軸からズレていないか？」
そう迷った時に、戻る場所になる。
それがあるだけで、AIとの共創はかなり安定します。
電子書籍づくりにも、この判断軸は効いた
ここまで、主にClaude Codeで /cut を作った時の話や、Brand Harnessの例で説明してきました。
でも、この考え方はコーディングやブランド設計だけではなく、
文章づくりや電子書籍づくりにもそのまま使えます。
私は最近、Kindle本を出しました。
タイトルは、
『人を支えてきた仕事が、私に残らない — その力を、自分の未来に返す働き方』
です。
この本を作る時にも、たくさんの判断がありました。
どこまで個人的な話を書くのか。
どの言葉を残すのか。
どこを整えすぎないのか。
AIチームとの共創を、どんな形で表現するのか。
読者に強く売り込むのか、静かに手渡すのか。
ここでもやはり、必要だったのは判断軸でした。
AIはたくさんの案を出してくれます。
でも最後に、
「この言葉は残したい」
「ここは私の体温が消えている」
「これはきれいだけど、私の本ではない」
と決めるのは人間です。
電子書籍づくりでも、成果物として本ができただけではありません。
どう考えたか。
どう決めたか。
何を守ったか。
何を手放したか。
その記録も、私の未来に残るものになりました。
成果物だけでなく、判断の記録も未来の仕事になる
AIと働くことは、ただ作業を効率化することではないと思っています。
もちろん、早く作れる。
たくさん試せる。
ひとりでは難しかったことに手が届く。
そういう便利さはあります。
でも、私がいちばん大事にしたいのは、
AIとのやり取りをその場限りで終わらせないことです。
何を考えたか。
どう迷ったか。
なぜそれを選んだか。
どんな基準を守ったか。
それを残しておくことで、AIとの仕事は、ただの作業ログではなく、未来の資産になります。
Claude Codeで /cut を作った時も、
Brand Harnessのような判断の仕組みを作る時も、
電子書籍を作った時も、
共通していたのは同じでした。
成果物だけではなく、判断を残すこと。
それは、次の仕事に使える。
次の発信に使える。
次のAIチーム運用に使える。
つまり、判断の記録もまた、未来の仕事になる。
AIに全部任せるためではなく、
AIと一緒に、迷わず進むために。
そのために私は、GitHubに decision と rule を残しています。
おわりに
AIは、これからもっと自律的に動くようになると思います。
でも、AIがどれだけ動けるようになっても、
人間側の判断軸がいらなくなるわけではありません。
むしろ、AIが動けるようになるほど、
人間は「何を大事にするのか」を言葉にしておく必要がある。
私はそう感じています。
decision と rule は、そのための小さな仕組みです。
難しいことをしているわけではありません。
ただ、決めたことと、その理由を残しているだけです。
でも、その小さな記録が、AIチームとの共創を支えてくれています。
AIに毎回うまく指示するより、
AIが迷った時に戻れる場所を作る。
それが、これからのAI活用で大事になるのではないかと思っています。
