AI にプロジェクトの「免疫システム」を持たせたら、開発が壊れなくなった

から | | AI, 技術・コンピュータ・プログラム
コメントを残す

はじめに

Claude Code や Cursor で AI と一緒に開発していて、こんな経験はないだろうか。

  • AI が「前に決めた仕様」を忘れて、勝手に別の方向に走り出す
  • 「ちょっと直して」と頼んだら、関係ない部分まで壊れた
  • ドキュメントと実装が乖離して、どっちが正しいのかわからない
  • セッションが切れるたびに、毎回ゼロから説明し直し

AI は優秀なシステムエンジニアであり、プログラマーだ。
でも翌日には「優秀だけど記憶喪失の同僚」になる。
毎回プロジェクトの背景を説明して、やってはいけないことを伝えて、前回の続きを思い出させて……正直、面倒だ。

この問題を仕組みで解決するために作ったのが Living Architect Model（LAM）だ。

以前、LAM の基本コンセプトを紹介する記事を Zenn に書いた。

今回は v4.0.0 で導入した免疫システムを中心に、LAM が「どうやってプロジェクトを守るか」を掘り下げてみる。

LAM をざっくり振り返る

詳しくは前回の Zenn 記事に書いたので、ここでは要点だけ。

LAM は AI を「コードを書く道具」から「プロジェクトの設計者 兼 門番」に変えるプロトコルセットだ。GitHub にテンプレートリポジトリとして公開していて、自分のプロジェクトにコピーするだけで使える。

普通の AI アシスタントは、聞かれたことに答えて、言われた通りにコードを書いて、セッションが切れたら全部忘れる。

LAM を入れると、AI の振る舞いが根本的に変わる。

  • 記憶に頼らず、毎回ファイルを開いて確認してから動く
  • 曖昧な仕様や低品質なコードを通さない
  • 「設計 → 実装 → 監査」の手順を自分から守る
  • コードを変える前に影響範囲を調べる

要するに、AI が作業者ではなく「プロジェクトの番人」になる。

3つのフェーズと承認ゲート

AI に「この機能を作って」と言うと、いきなりコードを書き始める。仕様が曖昧なまま書いたコードは、だいたい後から「そうじゃなかった」になる。

LAM では開発を3つのフェーズに分けて、これを防ぐ。

PLANNING（設計フェーズ）

  • コード生成を禁止
  • 要件定義 → 設計 → タスク分解を、承認ゲートを挟みながら進める
  • 各ステップでユーザーが「承認」と言うまで次に進めない

BUILDING（実装フェーズ）

  • TDD（テスト駆動開発）を厳守
  • テストを先に書いてから実装する Red-Green-Refactor サイクル
  • 仕様書なしの実装は禁止

AUDITING（監査フェーズ）

  • コードレビューと品質チェック
  • 仕様とコードの整合性を検証
  • 問題をリスクレベルで分類（自動修正できるもの / 報告が必要なもの / 人間の判断が必要なもの）

フェーズの切り替えは /planning、/building、/auditing とコマンドを打つか AI に頼むだけ。AI が自動的にモードを切り替えて、フェーズに合った行動をとってくれる。

承認ゲート: 勝手に進ませない仕組み

フェーズを分けるだけでは実は不十分で、AI は「よさそうだからどんどん進めよう」と暴走することがある。PLANNING で仕様を決めている最中に、勝手に設計に入ってしまうこともある。

そこで LAM では、PLANNING フェーズの中にも承認ゲートを設けている。

アイデア → 要求仕様 → [承認] → ADR・設計 → [承認] → タスク分解 → [承認] → BUILDING

ユーザーが「承認」と言わない限り、AI は次のステップに進めない。仕様書を出力したら一度止まって「これでよいですか？」と確認する。設計が終わったらまた止まる。

これにより Claude の手綱を握ることができる。「知らないうちに変な方向に進んでいた」という事故がなくなる。承認の負荷は軽い――内容を読んで「承認」の一言を返すだけだ。でもその一言が、プロジェクトの方向性を人間がコントロールし続けるための安全装置になる。

v4.0.0: 免疫システム

ここからが今回の本題。v4.0.0 で導入したのが免疫システムだ。

人体の免疫と同じ発想で、病原体が入ってきたら自動で検知して排除する――あれをプロジェクトでもやりたかった。

権限等級（PG/SE/PM）

すべてのファイル変更にリスクレベルを自動分類する。

等級対象AI の行動
PG級typo修正、フォーマット調整自動で直す。報告もなし
SE級テスト追加、リファクタリング直した後にユーザーに報告する
PM級仕様変更、アーキテクチャ変更必ず人間の承認がないと進めない

「どこまで AI に任せるか」の線引きが、感覚ではなくルールで決まる。

具体的には、ファイルパスで自動分類される。

docs/specs/*.md    → PM級（仕様書）
docs/adr/*.md      → PM級（アーキテクチャ決定記録）
.claude/rules/*.md → PM級（ルール）
src/**             → SE級（ソースコード）

docs/specs/ を触ろうとしたら、AI が勝手に変えることはできない。必ず「これを変更してよいですか？」と聞いてくる。

Hooks による自動監視

Claude Code の Hooks 機能を使って、AI がファイルを操作するたびに自動チェックを走らせている。

PreToolUse（変更前チェック）
AI がファイルを書き換えようとする瞬間に発火する。対象ファイルのパスを見て権限等級を判定し、PM級なら警告メッセージを返す。

# 例: docs/specs/ への書き込みを検知
if [[ "$file_path" == docs/specs/* ]]; then
    echo "PM級: 仕様書への変更です。承認が必要です。"
fi

PostToolUse（変更後チェック）
テストの失敗→成功パターンを自動記録したり、src/ の変更後にドキュメント更新が必要かフラグを立てたりする。

Stop hook（ループ制御）
/full-review コマンドの自動収束ループを制御する。「監査 → 修正 → 再監査」を繰り返して、問題が0件になったら自動停止。無限ループ防止のため反復回数にも上限がある。

TDD 内省パイプライン

テストの失敗→成功パターンを自動で記録していて、同じ失敗が3回繰り返されると「こういうルールを追加しませんか？」と提案してくる。プロジェクトが経験から学んでいく感じだ。

1回目: パターンを記録
2回目: 観測回数をインクリメント
3回目: ルール候補を自動生成 → ユーザーに承認を求める

承認されたルールは .claude/rules/auto-generated/ に配置され、以降の開発で自動的に適用される。90日以上使われなかったルールは棚卸し対象として通知される。ルールは増え続けるのではなく、新陳代謝する。

Green State: 「完了」の定義

LAM には「Green State」という概念がある。以下の5条件をすべて満たして初めて「完了」と言える。

#条件内容
G1テスト全パスpytest / npm test 等
G2lint エラーゼロruff / eslint 等
G3対応可能 Issue ゼロPG/SE級は修正済み
G4仕様差分ゼロdocs/specs/ と実装の整合性
G5セキュリティチェック通過依存脆弱性 + シークレットスキャン

/full-review コマンドを実行すると、複数のサブエージェントが並列で監査を行い、自動修正→再監査のループを回して Green State に収束させる。人間は他の作業をしていてOK。

セーブ/ロード: セッション切れ問題の解決

Claude Code のセッションは揮発する。長時間の作業でコンテキストが逼迫したり、セッションが切れたりすると、それまでの文脈が失われる。

LAM にはこの問題を解決する4つのコマンドがある。

コマンド用途消費
/quick-save軽量セーブ（SESSION_STATE.md のみ）3-4%
/quick-load軽量ロード~1%
/full-saveフルセーブ（STATE + commit + push）~10%
/full-load詳細確認 + 復帰報告2-3%

この仕組みの詳細は別の Zenn 記事に書いた。

実際の使い方: 5分で始められる

1. テンプレートからリポジトリを作成

GitHub で「Use this template」をクリック。それだけ。

2. Claude Code を起動して /planning

claude

LAM の設定はテンプレートに全部入っているので、初期化コマンドは要らない。

起動したら /planning と打って、作りたいものを伝える。AI が壁打ち相手になって、要件を具体化し、設計書を書き、タスクに分解してくれる。承認ゲートを一つずつ通過していくので、勝手に変な方向に進むことはない。

3. 要件が固まったら LAM を適応

「LAM の全ファイルを確認して、このプロジェクトに必要な部分を適応させて」と伝えれば、AI が CLAUDE.md や README をプロジェクト固有の内容に書き換えてくれる。.claude/ や docs/internal/ といった汎用基盤はそのまま動くので触らなくてよい。

コマンドを覚える必要はない

コマンド一覧を暗記する必要はない。AI に「今何をすべき？」と聞けば、適切なコマンドを教えてくれる。

18リリースの旅

LAM は v1.0.0 から始まった。最初は単なるドキュメント集だった。

バージョン主な追加
v1.xプロトコル文書の整備
v2.0Gemini から Claude Code へ移行
v3.0フェーズ制御、サブエージェント、承認ゲート
v3.3ルールシステム（.claude/rules/）
v3.6スライドサイト、タスクオーケストレーション
v3.9/ship、/full-review、TDD品質チェック
v4.0免疫システム（権限等級、Hooks、TDD内省）

LAM は LAM 自身を使ってバージョンアップしてきた。
18リリースを重ねて、プロジェクトは一度も破綻していない。仕様とコードの乖離（ドリフト）もゼロ。
これは LAM の設計思想の証明だと思っている。

まとめ

AI がコードを書ける時代になった。問題はその先にある。書いたコードでプロジェクトが壊れないか？ ということだ。

LAM は、AI を「頼まれたことをやる人」から「プロジェクトを守る人」に変える。フェーズで暴走を防ぎ、承認ゲートで手綱を握り、免疫システムで健全性を自動維持する。

興味があれば、まずはスライドを見てほしい。5分で概念がわかる。

関連記事

MIT License | 質問やフィードバックは GitHub Issues へ

X（旧Twitter）は休憩にならない——AI開発者の脳疲労対策

から | | AI, 技術・コンピュータ・プログラム, 日記
コメントを残す

休憩してたつもりが休憩じゃなかった問題

5時頃起床。

ここ数日、プログラムにめっちゃハマっていまして、今は OATH-HARNESS というものを作っています。LAMとは方向性の違うハーネスです。

午前中で燃料切れ問題

これや他のプロジェクトを一生懸命作っていると……午前中で燃料が切れてしまって、午後が全然使い物にならないという体たらく。

Claude君に相談してみると、休憩中にXとか見るのはダメということでした。 「脳が休まらないんですよ」とのこと。

休憩してるつもりが、休憩になってなかった。

……無念。

対策：ポモドーロ＋瞑想

というわけで、初心に返って ポモドーロタイマー を導入してみようかと思っています。

せっかくなので、OATH-HARNESSを使って無駄に超豪華なポモドーロタイマーを作らせようとも企んでいます。まあオースハーネスのテストみたいなつもりですね。どう豪華にしたところでたかが知れているとは思うんですが（笑）。

それと、脳みその休憩には瞑想が非常に有効だということもわかったので、そちらも取り入れていく予定です。

新機能をいろいろ作っているから消耗も激しいんでしょうね。さらに毎日続けているというのも大きいと思います。ちゃんと脳を休ませながら走り続けるのが今後の課題です。

📌 OATH-HARNESSの詳細についてはまた別記事で紹介予定。

Claude Code を「設計者」にする — Living Architect Model の紹介

から | | 技術・コンピュータ・プログラム, 日記
コメントを残す

TL;DR

Claude Code は放っておくと設計を飛ばしてひたすら実装する。LAM（Living Architect Model）は、3フェーズの承認ゲート・3視点での意思決定・TDD 強制・Subagent の自動割り当てによって、Claude Code を「コーディングマシン」から「設計者」に変えるフレームワーク。個人〜小規模開発向け。使うほどプロジェクト固有の知識が蓄積されてフレームワークごと育つので “Living” と名付けた。

GitHub: https://github.com/sougetuOte/LivingArchitectModel

はじめに

Claude Code を使っていて、こんな経験はないだろうか。

  • ちょっとした機能追加のつもりだったのに、気づいたらテストもないコードが大量にできていた。
  • 仕様書を書いたはずなのに、実装が終わる頃には中身が全然違うものになっていた。
  • 前に決めたことを AI が覚えていなくて、同じ議論を何度もやり直した。

私も全部やった。今はLAMがあるのでやらかすことはほぼほぼなくなった。

Claude Code は優秀だ。言われたことを高速に、高品質に実装してくれる。ただ、放っておくと「言われたことをひたすら実装するマシン」になる。設計を飛ばす。テストを後回しにする。ドキュメントを忘れる。人間がやりがちなことを、AI もまた同じようにやるのだ。

この問題をどうにかしたくて作ったのが Living Architect Model（LAM） だ。

概念の説明スライドも置いてあるので、ざっくり知りたい方はそちらからどうぞ。

LAM に至るまでの話

claude-friends-templates — 最初の試みと失敗

LAM の前に、claude-friends-templates というリポジトリを作っていた。

きっかけは Vibe コーディングでの「長期記憶」の問題だった。Claude Code はセッションが切れると文脈を忘れる。長期的なプロジェクトだと、毎回同じ説明をするのが面倒になる。Cline で公開されていた長期記憶のマニュアルを参考にして、Claude Code 向けに似たようなものを作り始めた。

ここまではよかった。

Claude Code の新機能が出るたびに追従して、hooks を追加し、commands を追加し、あれもこれもと付け足していった。結果、複雑になりすぎて破綻した。 何でもできるようにしようとした結果、設定ファイルが肥大化し、何がどこにあるのかわからなくなった。

「全部入り」は個人開発には重すぎた。これが最初の、そして一番大きな教訓だった。

反省から生まれた LAM

claude-friends-templates の失敗から学んだことは割とシンプルだった。

スコープを絞ること。個人や小規模開発に必要なものだけにする。バイナリは入れない。テキストファイルだけで完結させて依存を最小限にする。プロジェクトの成長に合わせてルールを変えられる構造にする。そして何より、AI の暴走を止める仕組みが要る。フェーズ管理と承認ゲートで「うっかり実装」を防ぐ。

こうして LAM が生まれた。

LAM の仕組み

CLAUDE.md — プロジェクトの「憲法」

LAM の中心にあるのは CLAUDE.md だ。Claude Code がプロジェクトを読み込んだとき、最初に参照するファイル。プロジェクトにとっての 「憲法」 みたいなものだと思ってもらえればいい。

ここで大事なのは、Claude に対して「お前はコードを書く人じゃない」と宣言しているところだ。Claude の役割は「プロジェクト全体の整合性を守る設計者（Architect）であり門番（Gatekeeper）」と定義している。

真実の優先順位も決めてある。

ユーザーの意志が最優先、次にプロセス文書、それから仕様書、最後に既存コード。コードと仕様が矛盾したら、仕様が正しい。
あと、「覚えているはず」に頼らず、必ずファイルを検索・確認してから回答すること。これだけで Claude の振る舞いはかなり変わる。

「コーディングアシスタント」から 「設計者」 への役割の転換だ。

3フェーズ + 承認ゲート

LAM は開発プロセスを PLANNING、BUILDING、AUDITING の3つのフェーズに分けている。

  • PLANNING では要件定義・設計・タスク分解をやる。コード生成はやってはいけない。
  • BUILDING では TDD で実装する。仕様なしの実装はやってはいけない。
  • AUDITING ではレビューと監査をやる。コードの直接修正はやってはいけない。

で、ここが肝なのだが、各サブフェーズが終わるたびに承認ゲートが入る。ユーザーが「承認」と言わないと次に進めない。

要件定義が終わったら承認。設計が終わったら承認。タスク分解が終わったら承認。実装が終わったら承認。そして監査。

これにより「まだ要件が固まってないのに実装が始まっていた」という事故を防ぐ。PLANNING フェーズで「実装して」と頼むと、Claude は警告を出して選択肢を提示する。意図的に進めることもできるが、少なくとも「意識せずに飛ばす」ことはなくなる。

全自動にならないのは制約でもあるが、同時に安全装置でもある。「全部任せて寝て起きたら完成」にはならない。が、寝て起きたら仕様と違うものができていたという事故も起きない。個人開発ではこのバランスがちょうどいいと思っている。

3 Agents Model — 一人ブレストの仕組み

個人開発で困るのは、設計のレビュー相手がいないことだ。自分一人で考えていると、どうしても盲点が出る。

LAM には重要な意思決定のとき、Claude が3つの視点で議論する仕組みがある。推進者（Affirmative）がメリットを主張し、批判者（Critical）がリスクを指摘し、調停者（Mediator）が両者を統合して結論を出す。

たとえば認証方式を選ぶとき。推進者が「JWT はステートレスでスケーラブル」と言う。批判者が「トークン漏洩リスクや XSS の懸念がある」と指摘する。調停者が落とし所をまとめる。一人で考えるより穴が減るし、少なくとも「考慮すべきだったのに見落としていた」というケースがかなり減った。

lam-orchestrate — タスクの分解と並列実行

Claude Code には「Subagent が他の Subagent を呼べない」という制約がある。Anthropic 公式の Agent Teams 機能もあるが、まだ負荷が高い。

そこで作ったのが lam-orchestrate だ。

Skill ファイル（SKILL.md）が Coordinator 役として振る舞い、与えられたタスクを分析して Wave に分解し、適切な Subagent に割り当てて並列実行する。ただ Subagent を呼ぶだけではなく、Coordinator がタスクの性質を見て「これは要件分析が先、設計はその結果を待ってから」といった依存関係を判断してくれるのがポイントだ。

Main Claude が中継することで擬似的な3層構造を実現していて、8種の専門 Subagent（要件分析、設計、タスク分解、TDD 実装、品質監査、ドキュメント作成、テスト実行、コードレビュー）が必要に応じて呼び出される。

実行前に必ず計画を提示して承認を得るので、何が起こるかわからないまま走り出すということはない。途中で要件が変わっても「計画変更プロトコル」で対応できる。

小規模開発ならこれで十分だ。将来 Agent Teams がもっと安定して使いやすくなったら、そちらに移行することも考えている。

LAM で楽になったこと

実際に使っていて一番助かっているのは「うっかり実装」がなくなったことだ。3フェーズと承認ゲートのおかげで、仕様を飛ばして実装に入るということがまず起きない。これだけでも作った甲斐がある。

3 Agents の一人ブレストもかなり重宝している。個人開発だとどうしても自分の思い込みで突っ走りがちで、後から「ここ考えてなかった」となることが多かった。今は重要な判断のところで自動的に複数の視点が出てくるので、その手の事故が減った。

ちなみに、最近はこれに加えてGoogleのAntigravityにレビューを依頼することがある。違うAIに頼むとまた別の視点が入りClaudeだけでは出てこないものが浮かび上がる。

TDD が強制されるのも地味に効いている。テストを書かないと実装に進めないので、品質の底上げになる。面倒ではあるが、後で「テスト書いてなかったからどこが壊れたかわからない」という地獄を見ることを考えると、はるかにマシだ。

あと、ドキュメントが腐りにくくなった。仕様とコードをセットで更新するルールがあるので、「ドキュメントと実装が全然違う」という状態になりにくい。完全ではないが、何もルールがない状態よりずっといい。

サイクルを重ねるほど仕様書や ADR（アーキテクチャ決定記録）やルールが溜まっていって、次の開発が速くなるのも実感している。CLAUDE.md や rules/ が使いながら洗練されていく。だから “Living” Architect Model という名前にした。最初はテンプレートだったものが、3サイクルも回せばそのプロジェクト専用の開発ガイドに育っている。

LAM の限界

とはいえ万能ではない。正直に書いておく。

まず、良い仕様を自動で書いてくれるわけではない。ゲートは仕様を「作ること」を強制するが、仕様の「質」はユーザー次第だ。ゴミみたいな仕様を承認すれば、ゴミみたいな実装が出てくる。ここは変わらない。

完璧なコードが出てくるわけでもない。TDD で品質の底上げはするが、設計判断の最終責任は人間にある。承認ゲートがあるということは、承認する人間の判断力がボトルネックになるということでもある。

大規模チーム向けでもない。個人から小規模チーム向けに作っている。CI/CD 統合とか権限管理とかは範囲外だ。

初期の学習コストもある。docs/internal/ に8つのプロセス文書があって、全部読む必要はないが、構造を理解するまでに少し時間がかかる。

要するに LAM は「AI を賢くする魔法」ではない。「AI と人間の協業プロセスを構造化するフレームワーク」だ。プロセスがあることで品質が上がるが、プロセスに乗せるものの質は人間が担保する。ここを勘違いすると期待外れになると思う。

今後のこと

LAM はまだ進化の途中だ。自分で使いながら改善を続けている。

新しい Claude Code の機能が出たり、他の人の開発プロセスで取り込めそうなアイディアを見つけたら、積極的に入れていくつもりだ。Agent Teams が安定してきたらそちらへの移行も検討する。

興味がある方は GitHub のリポジトリを覗いてみてほしい。テンプレートとして使えるようになっているので、自分のプロジェクトに導入して試すこともできる。

概念の説明スライドもあるので、まずはそちらからどうぞ。

この記事の内容は LAM v3.7.0 時点のものです。

フィルターバブルは本当に「悪」なのか？ — 人類のハードウェアとAIエージェント時代の処方箋

から | | 技術・コンピュータ・プログラム
コメントを残す

フィルターバブルとエコーチェンバー、似てるけど違う話

最近やたらと耳にする「フィルターバブル」と「エコーチェンバー」。似たような文脈で使われるけど、ちょっと違う。エコーチェンバーは同じ意見の人たちが集まって声を反響させ合う現象。フィルターバブルはアルゴリズムが「あなたの好きそうな情報」だけを選んで見せてくる仕組みのこと。今回はフィルターバブルの方に注目して書いてみたい。

2026年2月の衆院選で自民が316議席を取って、リベラル側に衝撃が走った。「なんでこんな結果に？」「国民は騙されてる」みたいな反応が噴出したんだけど、これって典型的なフィルターバブルの帰結だと思う。バブルの中では「高市政権は失敗だらけ」「国民は怒っている」という情報が循環していて、それが現実だと思い込んでいた。蓋を開けたら316議席。あのショックの大きさ自体が、バブルの厚さを物語っている。

でもね、ここで「だからフィルターバブルは悪だ、壊せ」と言い切るのは、ちょっと待ってほしい。

なぜフィルターバブルは存在するのか — 人類というハードウェアの話

人間の脳って、アフリカのサバンナで20〜30人の群れで暮らしていた頃のハードウェアのまんまなんだよね。ダンバー数って言って、安定した社会関係を維持できるのが150人程度。実際の生活単位はもっと少なくて、20〜30人がせいぜい。その規模なら全員の顔がわかるし、意見が違っても「まああいつはああいう奴だから」で済ませられた。

それが今、SNSで数万、数十万の「意見」が一気に流れ込んでくる。顔も名前も文脈もわからない人たちから。これ、脳の設計仕様を完全に超えてるんだよ。

だからフィルターバブルが自然発生するのは、防衛本能として当然のことだと思う。処理しきれない情報を遮断して、自分が理解できる規模のコミュニティに絞り込む。これは故障じゃない。正常な動作だ。

それを許さないネットの時代と社会

問題は、社会の方がその本能的な規模では回らないということ。

民主主義って、自分と全く違う背景の人間と同じ制度を共有するという、進化的にはかなり不自然なことを要求してくる。1億人が一つの政治体制の下で共存するなんて、ご先祖様の脳は想定していない。

さらにSNSの常時接続環境では、気合が入ってないときでも勝手に反対側の極端な意見が流れてくる。自分のコンディションに関係なく殴られる。フィルターバブルの問題って「情報が偏ること」だけじゃなくて、「バブルの外の情報に触れるタイミングを自分でコントロールできない」ことも含めてのものなんだと思う。

バブルに閉じこもれば社会が分断される。かといってバブルを壊したら本能が耐えられない。なかなかに厄介な矛盾だ。

たまに外の「毒」を取り入れる — ただし準備が必要

じゃあどうするか。完全にバブルの外に出る必要はないと思う。というか、それは危険ですらある。

政治的な立場って、単なる意見の集合じゃなくて、その人の世界観や価値観、もっと言えば「自分は何者か」というアイデンティティに直結している。バブルの外に出るということは、自分の世界観を根本から揺さぶられる体験になりうる。心理的な安全基盤がない状態で「お前の信じてたこと全部間違ってたよ」と突きつけられたら、壊れる人が出てもおかしくない。

だから「たまにちょっと外を見に行く」くらいがちょうどいい。「あっち側から見るとこう見えるのか」を少しだけ覗いて、自分の足場に戻ってくる。

ただしこれも、ある程度以上モチベーションがあって気合が入っているときじゃないと危ない。疲れてるときとか精神的に余裕がないときにやると、冷静に処理できなくて、感情的に反発するか逆に飲み込まれるかのどちらかになる。どっちにしても良い結果にならない。

要するに、バブルの外の情報は「毒」に近い。適量を、体力のあるときに、意識的に摂取するから薬になる。浴びせられたらダメージにしかならない。

AI時代の処方箋 — 秘書AIによる「事務レベル協議」

ここで、せっかくのAI時代なんだから何かいい手はないかと考えてみたい。

外交の世界には「事務レベル協議」というものがある。首脳同士がいきなりぶつかると感情的になって壊れるから、事前に事務方が論点を整理して、落としどころの候補を作っておく。それと同じことを、AIが個人のためにやってくれるとしたらどうだろう。

例えばこんなイメージだ。

反対側の意見に生身で触れるとダメージがある。でも秘書AIが「あちら側の主要な論点はこの3つで、うち1つはあなたの立場と実は共通点がある」みたいに整理してくれれば、感情的な防衛反応を起こさずに中身を検討できる。致命的な衝突を避けるためのエアバッグとしてのAI。あくまでも「下ごしらえ」であって、最終的な判断は人間がやる。ここが大事で、AIが全部整理して「はいこれが正解です」と出してしまったら、人間の思考力そのものが衰える。筋トレと同じで、負荷がないと能力は退化するから。

もちろん「AIに支配されてる」問題は出てくる。AI自身のバイアスをどうするのかという話もある。でもたぶん解決策は「完全に中立なAIを一つ作る」ではなくて、AI自身が「自分はこういう前提で整理しました、別の前提だとこう見えます」と透明性を持って提示する方向だろう。この世界に絶対座標はない。お互いの偏りの相対的な位置を把握してから話を始めるのが、現実的な出発点だと思う。

AIエージェントの時代がそこまで来ている

実はこの「秘書AI」の構想、もう現実に近づいてきている。

AnthropicのClaude Cowork、MicrosoftのCopilot Agents、GoogleのProject Mariner、OpenAIのOperatorなど、AIエージェントサービスが次々と登場している。今はまだファイル管理やタスク処理が中心だけど、これらが発展していった先に「認知的な中間層」としてのAIが来るのは自然な流れだと思う。

情報の下ごしらえをして、致命的な衝突にはエアバッグとして機能し、でも最終判断は人間に委ねる。そういうAIエージェントが一人一人に付く時代。

人類のハードウェアが処理できない規模の情報と多様性に対処するために、何らかの「認知的な中間層」は必要になる。それがAIエージェントという形で実現するなら、フィルターバブルの問題にも一筋の光が差すかもしれない。

もっとも、そのAIエージェント同士が事務レベル協議をして、それでも折り合いがつかなかったらどうなるんだっていう問題は残るけどね。まあそれは、また次の話ということで。

脳みそは積み替えられない――だからAIに底上げしてもらうという選択

から | | 技術・コンピュータ・プログラム
コメントを残す

AIによる実装支援が当たり前になり、簡単なコードであれば、実装からテスト、結合までをAIの中だけで完結できる場面が増えてきた。体感的には、プログラムを「書く」という作業そのものにかかる時間は、以前の10分の1、場合によっては100分の1にまで圧縮されつつあるように思う。一方で、人間側の処理速度はほとんど変わっていない。脳みそは積み替えられない以上、ここにギャップが生じるのは当然だ。

結果として、いま目立ち始めているのが「人間がボトルネックになる」現象だ。コードは一瞬で出てくるのに、それを読む、レビューする、理解するところで詰まる。Vibe Coding初期にも似た話はあったが、最近はモデルの性能向上によって、この問題がより顕在化してきた印象がある。

そこで一案として考えられるのが、AIにプレゼンテーション用のスライドを作らせるというやり方だ。コードそのものを全部追うのではなく、「何を作ったのか」「どこを変更したのか」「どこが危険そうか」をスライドという形で要約してもらう。そこから人間が質問を投げたり、特定の部分だけ掘り下げたスライドを追加で作らせたりすれば、ソースを最初から最後まで読むよりも、実用上は十分にカバーできるのではないかと思う。

確かに、AIに説明されるという構図は屈辱的に感じる人もいるかもしれない。しかし、これは人間の価値を下げる話ではなく、判断や設計といった本来人間が担うべき部分に集中するための底上げだ。同じことは実装だけでなく、設計書をAIに書かせる場合にも言える。叩き台を作らせ、違和感のあるところだけ人間が詰める方が、タイパとしては合理的だ。

私は個人で動いており、扱っているプログラムもそれなりの規模だが、それでも全体を把握し続けるのは徐々に厳しくなってきている。チーム開発であればなおさらだろう。AIが強くなり続ける一方で、人間の限界が変わらない以上、こうしたやり方は案外、悪くない手なのではないかと思っている。

書くことがない日なのか？いやある（反語）

から | | 技術・コンピュータ・プログラム, 日記
コメントを残す

気がついたら夕方になっていた。

昨日は夕方になってからClaudeCodeの改造をした。昨日の日記に書いた通り、Status Lineと記憶関係の変更である。serenaはデータを確認したところ、私のProjectでは活用されていないと判明。削る方向で決定し実装した。

Status Lineを利用することにより、運用が勘頼りではなく、数字を見ながらsaveをしたり、セッションを切り替えたりということができるようになった。どういう動作でコンテキストを使っていくのかがいまいちまだわかってないので、ギリギリを攻めることはできないのだが、残り数%になってからやきもきせずに済むようになったので精神衛生上、非常に良い感じだ。

プログラムで疲れたら少し創作の書き物をしてみる。あまりいいものにならない。ちょっと残念である。クロードの評価も少し辛め。

今日、土曜日になってからはプログラムを触っていない。創作もしていない。採点とか成績処理の準備をしたりとか、そんなんばっかりである。非常にめんどくさい。気が重い。

Excelで処理をしていくのだが、そこで面白かったのは、Excelに載ったClaudのプラグインである。大まかな指示を伝えると式を作ってくれる。自分の理解が怪しいところでは具体例で、「こことここをこうしたらこうしてくれ」みたいな風に頼むとちゃんとやってくれた。気が重い処理も簡単に作ってくれて非常に心のストレスが解消された。

と、こんなわけで、昨日から今日何にも書くことがない、日記に書くことがないと思っていたのだが、実際に書いてみると、わちゃわちゃと書くことはあったようだ。

案外そんなもんである。

Opus4.6とClaudeCode運用戦略

から | | 技術・コンピュータ・プログラム, 日記
コメントを残す

今朝未明、Claude Opus 4.6がリリースされた。Sonnet 5リークとはなんだったのか。まあいい。Opus 4.6に対応しよう。

詳しい数値とかは有識者の方にお任せするとして、こちらに関係するものだけ。
注目していた1MコンテキストウィンドウはベータかつAPI直接のみで、Claude Codeからは使えない。200K固定のまま。かなり残念。一方でDev Agents（Agent Teams）やSubagentのメモリ機能は面白い。Subagentにmemoryフィールドを持たせ、MEMORY.md作る。これでセッション横断の秘伝のタレができる。使いこなさないとありがたみはわからないだろうけど、ワクワクする。

大雑把に機能確認をしたところで、LAM( https://github.com/sougetuOte/LivingArchitectModel )のメモリ戦略を見直した。

最近問題としているのは圧縮処理だ。残りが少なくなってるのを認識した時点でセーブ処理を行い、セッションの切り替えをするのだが。SerenaとDailyコマンドを併用し、コンテキストの約7-8%を消費している。200Kの8%は16Kトークン。これは痛い。また、serenaはCLAUDE.mdで明示的に指示しないと、grepで済ませてしまう傾向があるらしい。セーブ処理でトークンを消費しても、セッション時にはあまり使われていない可能性がある。私のプロジェクト規模（個人開発、全体像が頭に入る程度）では、Serenaの恩恵自体が薄いのかもしれない。

serenaを常駐させるだけでコンテキストを圧迫するので、対策を考える。まずは、セッションのセーブ処理だけを目的とした軽量な/quick-save（SESSION_STATE.mdのみ、3-4%）と、フルセーブ(SESSION_STATE.md + git commit & push + dailyコマンド)に分離する方針を立てた。作業セッションのコンテキストを開発に全振りするという考え方。StatusLineでコンテキスト残量を常時監視しつつ、残り15-20%を切ったらquick-saveでセッションをexitする。クイックセーブについては恐らく10%程度から実行すれば十分だと思うが。そうすれば、auto-compactに怯えなくて済む。serenaの常駐を止めればコンテキストを運用に使える量が増える。より余裕を持って使えるようになるだろう。

まだ机上の空論だが、固い戦略だと思うので恐らく外すことはなかろう。まずは、StatusLine導入から実際に試していく。

プログラミング教育のAI時代への転換 ―『書く技術』から『導く設計』へ―

から | | 技術・コンピュータ・プログラム, 教育, 日記
コメントを残す

ソフトウェアの作成がAIツールによってソースコードの作成からアーキテクト、マネージメントに移りつつ有る。
それに伴い現在のプログラミング初等教育は、ある種の岐路に立たされていると感じる。初学者が学ぶ「低レイヤーな基礎」と、実務で行う「AIを動かすための高レイヤーな設計」。この乖離を埋める鍵は、開発における「ガードレール」の捉え方にあるのではないか。

これからの教育は、これまでと違うアプローチが必要だ。第一段階では、AIツールベンダーが用意しているガードレールを活用し、プログラム作成の成功体験を与える。バイブコーディングの波に乗り、まずはとにかく完成品を積み上げること。この成功体験を通じて、ソフトウェアの作成の全体像を体感させる。これは、今までの初心者教育には出来なかったことだ。これだけでもこれまでの教育方法を刷新する価値がある。
そのうえで、標準の与えられたガードレールでは不足が生じた段階になれば、ガードレール（設計図）を自ら設計する必要性を気づかせる。

自分でガードレールを引くためには、結局のところ、コンピュータがどう動くかという基礎的な理解が欠かせない。C言語やPythonの初歩を教える意味は、実装力を養うためではなく、AIに与える指示の妥当性を判断し、構造を破綻させないための「鑑識眼」を養うことに集約される。教育を否定するのではなく、出口を「設計」へとシフトさせる。それが私の考える、新しい時代の初等教育の姿だ。

では、書けない技術者についてどう考えるのか。これは作成のレイヤーが変わったと捉えるしかないのだろう。我々だってアセンブラは書けないのだから。

バイブコーディングのその先で

から | | 技術・コンピュータ・プログラム, 日記
コメントを残す

おはようございます。

結局、Claude Sonnet5は来ませんでしたね。夜中に起きた時にチェックしてみたんですが、Xのトレンドに上がってなくてがっかりしました。

昨日は年度末特有のドタバタでした。プログラムについてはほんの少ししか触ることができず、残念でした。

私はClaudeCodeを使ってプログラムを作成していますが、自分のプロジェクトに限って言えば、ここ数ヶ月まともにソースコードを見たことすらありません。LAMによるガードレールを作り、テスト計画を立て、リファクタリングや実際の使用してのユーザーテストなどをやることで、片がついてしまうからです。細かいところの最適化についてはいろいろあるんでしょうけれども、使用していての問題は特にありません。

私の場合は計画を立てたり構造を考えたりするのは好きなんですが、コーディング能力というといまいちです。なので、私の場合バイブコーディングを行うのがかなり性に合っています。今やバイブコーディングというより、何なんですかね、このプロジェクトの作り方は。実際全然コーディングしてないので、これはプロダクトと言うべきなのか何なのか。

この作り方が標準的になってくるのであれば、現在よりもコーディングの職人的なところが排除されていき、工芸品より工業的になっていくのではないかと思います。大規模なプロジェクトについては作り方は知らないのですが、中規模・小規模となってくると、どうしてもメンバーの俗人性というのが反映されてしまいます。設計や指示の仕方などを統一していけば、ClaudeCodeなどのツールが一定の水準で物を作り込んでくれる。そういう風になるのではないかなと考えています。

Sonnet5の噂とLAMの更新

から | | 技術・コンピュータ・プログラム, 日記
コメントを残す

昨日2月2日、AnthropicのClaude Sonnet 5リリースのリークが出た。そのリークを信じるのであれば、明日未明、2月4日未明にリリースされるはずだ。様々なアップデートが、その中にサブエージェントなどにチームを組ませるという項目があった。嬉しい反面、気になるところが出てくる。

私が現在利用している自作ソフトに「LivingArchitectModel」というものがある。これは一言で言うなら「Claude Code のための行動規範フレームワーク」だ。cc-sddやspec-kitみたいなもんだと思ってもらえば良い。今作っているソフトはこの LivingArchitectModel をテンプレートとして作っている。

そして現在ちょうどこのLAMについて大規模なアップデートをしようと考えていた。何かというとサブエージェントのチーム化だ。つまり、このリーク記事のSonnet5としっかり被ってしまうというわけだ。先日、ClaudeOpusの4.5に、「agent swarm」の記述があったという話も記憶に新しい。なんにせよ、エージェントのチーム化というのはホットなキーワードである。

私のような一般人が作るより、Anthropicの最高の技術者たちが作った方がいいに決まっているし、標準化されているものを使うのはいいテクニックだ。私はしばらく待つことにした。

ネット上のアナリストによると、Opusが出てまだ10週間しか経っていない。Anthropicがここで新しいモデルを出すのは彼らのやり方に合わないという。確かにそれはある。ただ、それは周囲の状況を見て考えるとそうでないかもしれないと言える。

Gemini3Proが出てからのOpenAIの動きを考えてみてほしい。レッドアラートが出て、そしてすぐに5.2が発表された。それからもGoogleはGeminiを様々なサービスと組み合わせようとしている。Google ChromeとGeminiの一体化というのもまた一つある。そこでnano bananaが使えるというのは恐ろしい話だ。

そういう状況を考えると、Anthropicが彼らのやり方を破る可能性は十分にある。swarmにしても今回のリークにしてもそのマーケティングに当たるものかもしれない。

まあ何にせよ、私にできることはほんの少し待つだけだ。