齋藤貴洋 判断軸 — これだけ
長さで残さない。この20行が本体で、他のファイルは全部この根拠置き場。
迷ったらここだけ読む。ここに無いものは、まだ判断軸になっていない。
つくり方の判断軸
- AIの的中率が実用に届かないときは、精度を上げにいかず、AIが「確信あり」と言った部分だけ確定させ、残りは業務の物理法則（連番・時系列・慣習）で機械的に埋める。
- AIの出力が人の記録や顧客の手元に残るときは、プロンプトでの注意ではなく構造（禁止語・状態機械・確定操作は人間だけ）で守る。
- 同じ判定を複数の手段でできるときは、無料→安い→高いの階段を作り、高コストの工程には絞り込み済みのものだけを通す。
- 「運用開始後に必ず変える」と言える値は、コードの中に書かず、設定に出してリモートから配る。
- 対象データがすでに存在するなら、設計を書く前に実測する。実測は精度を上げるためでなく、機能を削るために使う。
- プラットフォームの標準機能で代替できるものは自前で書かない。 自分で書いたコードは、全部あとで自分の保守負債になる。
- 複数のAIや人を同時に走らせるときは、正典を1冊に固定し、他の文書はすべてその章番号を引用させる。
- 有限のもの（時間・ターン・金・人）を配るときは、終盤の必須分を先に予約してから、残りを可変部分に配る。
- 何かが足りないときは、現実世界（人・時間・再撮影）を動かす前に、デジタル側（台本・仕様・条件）を書き換えて吸収できないか先に探す。
- 自分以外の人が日常的に触るものは、相手がすでに使っている形式・構造に合わせる。新しいツールを覚えさせない。
守りの判断軸
- 顧客の受信箱に届くもの（メルマガ・一斉配信）は、どんな理由があっても機械に実行させない。人が管理画面から送る。
- 自動化の線引きは「消すかどうか」ではなく「不可逆か／外部に出るか」で引く。
- 顧客やユーザーに課しているルールは、自分の作業環境にも同じ厳しさで課す。事故が起きるとしたら、必ず自分側から起きる。
事業・時間の判断軸
- その日の顧客接点がゼロなら、どれだけ作っても「前進ゼロ」と判定する。
- 検証していない前提の上に積むときは、投下する時間の上限を先に決める。1人に当てるコストは、仕様書を1冊書くコストより圧倒的に安い。
- 動くものができた直後に思いついた追加機能は、その場で実装せず翌日の判断に回す。
- うまくいかないと分かったら粘らず方式ごと乗り換える。 ただし「測ってから」でなければ、それは撤退ではなくただの飽き。
- 時間は、好きな順ではなく事業価値の順に配る。 放っておくと必ず0→1の楽しい方に吸われる。
- 作ったものは、必ず他人に説明する1枚を作る。 説明できない状態は、設計が固まっていない状態であり、売れない状態でもある。
指示の判断軸
- AIに指示を出す前に、「完了条件」と「今回やらないこと」の2行を必ず足す。 この2行が、自分に最も欠けている。
自分の傾向（放っておくとこうなる・補正が要る）
- ユーザー0人でも設計を作り込める。ドキュメントの整合作業（番号の振り直し等）を始めたら、作り込みすぎのサイン。
- 動くものを見ると7分で4機能足せる。追加要望が3つ続いたら手を止める。
- 待ち時間ゼロを追うと、並列数が自分の把握限界を超える。「これ何の話だっけ」が出たら本数を減らす。
- AIには任せられるが、人には任せられていない。 委譲の量はAIと人で別々に数える。
- 苦手な領域（本番運用の設計・ログ・監視）は、意識しないと必ず後回しになる。デプロイした日は、その日のうちに監視を付ける。
このファイルの更新ルール
- 上限20行。 21個目を足したくなったら、既存のどれかを統合するか捨てる。捨てた理由は
decision-principles.mdに残す。 - 更新は月1回だけ。日々の気づきは daily と各長期ファイルに溜め、月末にここへ昇格させる。
- 昇格の条件は「2案件以上で実際に効いた」こと。1回しか効いていないものはまだ仮説なので、ここには上げない。
- 反証されたら消す。消したこと自体が学びなので、
failure-patterns.mdに反証の事実を残す。