最近、たまに右肩というか右腕が全体的に冷える。左手と右手で体温が違う時がある。
Claudeに相談したところ、脊椎もしくは首のあたりがおかしくなっているんじゃないかという話が出た。ただいろいろとストレッチをしたり、体を温めるようにすると治るので、ひょっとするとそういうのじゃなくて、姿勢が悪いんじゃないかと思い始めた。何より気象時には特に問題ない。しばらくデスクワークしているとそうなるからだ。
そうしてよくよく姿勢を考えてみると、椅子の位置がずいぶん後ろにありすぎる。そして前のミリにキーボードに覆いかぶさるようにしてキーを打っているということに気がついた。ストレートネックというより海老反りネックになってたのかもしれない。椅子の位置をずっと前の方に修正して今作業を始めているんだけれど、ディスプレイとの位置が近いのを除けば特に問題はないようだ。このまま色々と試して左腕右腕のことを確認していきたい。
いろいろ体質の問題やら病気の問題やらがあって、とても眠い人である。しかし最近は度を越して眠いことが多くなってきた。
いろいろと試してはみるものの、なかなか成果が上がらない。そこで一つ思いついたのが二酸化炭素チェッカーを買うということだった。学校などでは、例えば1時間に1回は換気をしようみたいなことを言われる。私の場合、そういう換気などはしていない。もしこれにデータ的な根拠があるのであれば、私の部屋は相当二酸化炭素が溜まっているはずだ。
で、実際に二酸化炭素チェッカーを買ってみた。「NDIRセンサーCO2モニター」というもの。二酸化炭素チェッカーには2種類あるようで、ライブで生の値が欲しいのであれば、このNDIR型というのが必要なんだそうだ。私が実際に買ったのは以下のもの。https://www.amazon.co.jp/dp/B09XXXKGJG
実際に測ってみて驚いた。結構二酸化炭素の数値が高くなる。400から500ぐらいが標準のようなのだが、あっという間に1000、2000となる。
二酸化炭素（CO2）濃度の目安と影響〜450ppm: 外気レベル。〜700ppm: 清浄な室内。〜1,000ppm: 許容範囲（1,000ppm以下が推奨基準）。1,000〜2,000ppm: 眠気、空気の汚れを感じる。2,000〜5,000ppm: 頭痛、倦怠感、集中力低下。5,000ppm〜: 長時間の滞在で有害なレベル
https://3rrr-btob.jp/archives/column/measuring-equipment/19403
そりゃ眠いはずである。私が過眠気味であることを除いても、これだと眠くなるはずだ。まあ他にもいろいろ原因はあると思うが、まずは二酸化炭素の濃度を減らそう。そういうわけで頻繁に空気交換をするようになった。今はそれほど寒さも厳しくないが、真冬だとこれは大変かもしれない。真夏でも大変かもしれない。電気代が上がってしまうだろうと思う。
結果として最近はさほど眠くならない。まだ実際に使い始めて10日ほどしか経ってないので、もう少し継続的に試す必要があるだろう。多く寝ないで済むということは、それだけ活動時間が伸び、いろいろとできる可能性が増える。過眠で悩む私にとってはそれだけでも嬉しい。
5時頃起床。
ここ数日、プログラムにめっちゃハマっていまして、今は OATH-HARNESS というものを作っています。LAMとは方向性の違うハーネスです。
これや他のプロジェクトを一生懸命作っていると……午前中で燃料が切れてしまって、午後が全然使い物にならないという体たらく。
Claude君に相談してみると、休憩中にXとか見るのはダメということでした。 「脳が休まらないんですよ」とのこと。
休憩してるつもりが、休憩になってなかった。
……無念。
というわけで、初心に返って ポモドーロタイマー を導入してみようかと思っています。
せっかくなので、OATH-HARNESSを使って無駄に超豪華なポモドーロタイマーを作らせようとも企んでいます。まあオースハーネスのテストみたいなつもりですね。どう豪華にしたところでたかが知れているとは思うんですが（笑）。
それと、脳みその休憩には瞑想が非常に有効だということもわかったので、そちらも取り入れていく予定です。
新機能をいろいろ作っているから消耗も激しいんでしょうね。さらに毎日続けているというのも大きいと思います。ちゃんと脳を休ませながら走り続けるのが今後の課題です。
📌 OATH-HARNESSの詳細についてはまた別記事で紹介予定。
Claude Code は放っておくと設計を飛ばしてひたすら実装する。LAM（Living Architect Model）は、3フェーズの承認ゲート・3視点での意思決定・TDD 強制・Subagent の自動割り当てによって、Claude Code を「コーディングマシン」から「設計者」に変えるフレームワーク。個人〜小規模開発向け。使うほどプロジェクト固有の知識が蓄積されてフレームワークごと育つので “Living” と名付けた。
GitHub: https://github.com/sougetuOte/LivingArchitectModel
Claude Code を使っていて、こんな経験はないだろうか。
私も全部やった。今はLAMがあるのでやらかすことはほぼほぼなくなった。
Claude Code は優秀だ。言われたことを高速に、高品質に実装してくれる。ただ、放っておくと「言われたことをひたすら実装するマシン」になる。設計を飛ばす。テストを後回しにする。ドキュメントを忘れる。人間がやりがちなことを、AI もまた同じようにやるのだ。
この問題をどうにかしたくて作ったのが Living Architect Model（LAM） だ。
概念の説明スライドも置いてあるので、ざっくり知りたい方はそちらからどうぞ。
LAM の前に、claude-friends-templates というリポジトリを作っていた。
きっかけは Vibe コーディングでの「長期記憶」の問題だった。Claude Code はセッションが切れると文脈を忘れる。長期的なプロジェクトだと、毎回同じ説明をするのが面倒になる。Cline で公開されていた長期記憶のマニュアルを参考にして、Claude Code 向けに似たようなものを作り始めた。
ここまではよかった。
Claude Code の新機能が出るたびに追従して、hooks を追加し、commands を追加し、あれもこれもと付け足していった。結果、複雑になりすぎて破綻した。 何でもできるようにしようとした結果、設定ファイルが肥大化し、何がどこにあるのかわからなくなった。
「全部入り」は個人開発には重すぎた。これが最初の、そして一番大きな教訓だった。
claude-friends-templates の失敗から学んだことは割とシンプルだった。
スコープを絞ること。個人や小規模開発に必要なものだけにする。バイナリは入れない。テキストファイルだけで完結させて依存を最小限にする。プロジェクトの成長に合わせてルールを変えられる構造にする。そして何より、AI の暴走を止める仕組みが要る。フェーズ管理と承認ゲートで「うっかり実装」を防ぐ。
こうして LAM が生まれた。
LAM の中心にあるのは CLAUDE.md だ。Claude Code がプロジェクトを読み込んだとき、最初に参照するファイル。プロジェクトにとっての 「憲法」 みたいなものだと思ってもらえればいい。
ここで大事なのは、Claude に対して「お前はコードを書く人じゃない」と宣言しているところだ。Claude の役割は「プロジェクト全体の整合性を守る設計者（Architect）であり門番（Gatekeeper）」と定義している。
真実の優先順位も決めてある。
ユーザーの意志が最優先、次にプロセス文書、それから仕様書、最後に既存コード。コードと仕様が矛盾したら、仕様が正しい。
あと、「覚えているはず」に頼らず、必ずファイルを検索・確認してから回答すること。これだけで Claude の振る舞いはかなり変わる。
「コーディングアシスタント」から 「設計者」 への役割の転換だ。
LAM は開発プロセスを PLANNING、BUILDING、AUDITING の3つのフェーズに分けている。
で、ここが肝なのだが、各サブフェーズが終わるたびに承認ゲートが入る。ユーザーが「承認」と言わないと次に進めない。
要件定義が終わったら承認。設計が終わったら承認。タスク分解が終わったら承認。実装が終わったら承認。そして監査。
これにより「まだ要件が固まってないのに実装が始まっていた」という事故を防ぐ。PLANNING フェーズで「実装して」と頼むと、Claude は警告を出して選択肢を提示する。意図的に進めることもできるが、少なくとも「意識せずに飛ばす」ことはなくなる。
全自動にならないのは制約でもあるが、同時に安全装置でもある。「全部任せて寝て起きたら完成」にはならない。が、寝て起きたら仕様と違うものができていたという事故も起きない。個人開発ではこのバランスがちょうどいいと思っている。
個人開発で困るのは、設計のレビュー相手がいないことだ。自分一人で考えていると、どうしても盲点が出る。
LAM には重要な意思決定のとき、Claude が3つの視点で議論する仕組みがある。推進者（Affirmative）がメリットを主張し、批判者（Critical）がリスクを指摘し、調停者（Mediator）が両者を統合して結論を出す。
たとえば認証方式を選ぶとき。推進者が「JWT はステートレスでスケーラブル」と言う。批判者が「トークン漏洩リスクや XSS の懸念がある」と指摘する。調停者が落とし所をまとめる。一人で考えるより穴が減るし、少なくとも「考慮すべきだったのに見落としていた」というケースがかなり減った。
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 がもっと安定して使いやすくなったら、そちらに移行することも考えている。
実際に使っていて一番助かっているのは「うっかり実装」がなくなったことだ。3フェーズと承認ゲートのおかげで、仕様を飛ばして実装に入るということがまず起きない。これだけでも作った甲斐がある。
3 Agents の一人ブレストもかなり重宝している。個人開発だとどうしても自分の思い込みで突っ走りがちで、後から「ここ考えてなかった」となることが多かった。今は重要な判断のところで自動的に複数の視点が出てくるので、その手の事故が減った。
ちなみに、最近はこれに加えてGoogleのAntigravityにレビューを依頼することがある。違うAIに頼むとまた別の視点が入りClaudeだけでは出てこないものが浮かび上がる。
TDD が強制されるのも地味に効いている。テストを書かないと実装に進めないので、品質の底上げになる。面倒ではあるが、後で「テスト書いてなかったからどこが壊れたかわからない」という地獄を見ることを考えると、はるかにマシだ。
あと、ドキュメントが腐りにくくなった。仕様とコードをセットで更新するルールがあるので、「ドキュメントと実装が全然違う」という状態になりにくい。完全ではないが、何もルールがない状態よりずっといい。
サイクルを重ねるほど仕様書や ADR（アーキテクチャ決定記録）やルールが溜まっていって、次の開発が速くなるのも実感している。CLAUDE.md や rules/ が使いながら洗練されていく。だから “Living” Architect Model という名前にした。最初はテンプレートだったものが、3サイクルも回せばそのプロジェクト専用の開発ガイドに育っている。
とはいえ万能ではない。正直に書いておく。
まず、良い仕様を自動で書いてくれるわけではない。ゲートは仕様を「作ること」を強制するが、仕様の「質」はユーザー次第だ。ゴミみたいな仕様を承認すれば、ゴミみたいな実装が出てくる。ここは変わらない。
完璧なコードが出てくるわけでもない。TDD で品質の底上げはするが、設計判断の最終責任は人間にある。承認ゲートがあるということは、承認する人間の判断力がボトルネックになるということでもある。
大規模チーム向けでもない。個人から小規模チーム向けに作っている。CI/CD 統合とか権限管理とかは範囲外だ。
初期の学習コストもある。docs/internal/ に8つのプロセス文書があって、全部読む必要はないが、構造を理解するまでに少し時間がかかる。
要するに LAM は「AI を賢くする魔法」ではない。「AI と人間の協業プロセスを構造化するフレームワーク」だ。プロセスがあることで品質が上がるが、プロセスに乗せるものの質は人間が担保する。ここを勘違いすると期待外れになると思う。
LAM はまだ進化の途中だ。自分で使いながら改善を続けている。
新しい Claude Code の機能が出たり、他の人の開発プロセスで取り込めそうなアイディアを見つけたら、積極的に入れていくつもりだ。Agent Teams が安定してきたらそちらへの移行も検討する。
興味がある方は GitHub のリポジトリを覗いてみてほしい。テンプレートとして使えるようになっているので、自分のプロジェクトに導入して試すこともできる。
概念の説明スライドもあるので、まずはそちらからどうぞ。
この記事の内容は LAM v3.7.0 時点のものです。
気がついたら夕方になっていた。
昨日は夕方になってからClaudeCodeの改造をした。昨日の日記に書いた通り、Status Lineと記憶関係の変更である。serenaはデータを確認したところ、私のProjectでは活用されていないと判明。削る方向で決定し実装した。
Status Lineを利用することにより、運用が勘頼りではなく、数字を見ながらsaveをしたり、セッションを切り替えたりということができるようになった。どういう動作でコンテキストを使っていくのかがいまいちまだわかってないので、ギリギリを攻めることはできないのだが、残り数%になってからやきもきせずに済むようになったので精神衛生上、非常に良い感じだ。
プログラムで疲れたら少し創作の書き物をしてみる。あまりいいものにならない。ちょっと残念である。クロードの評価も少し辛め。
今日、土曜日になってからはプログラムを触っていない。創作もしていない。採点とか成績処理の準備をしたりとか、そんなんばっかりである。非常にめんどくさい。気が重い。
Excelで処理をしていくのだが、そこで面白かったのは、Excelに載ったClaudのプラグインである。大まかな指示を伝えると式を作ってくれる。自分の理解が怪しいところでは具体例で、「こことここをこうしたらこうしてくれ」みたいな風に頼むとちゃんとやってくれた。気が重い処理も簡単に作ってくれて非常に心のストレスが解消された。
と、こんなわけで、昨日から今日何にも書くことがない、日記に書くことがないと思っていたのだが、実際に書いてみると、わちゃわちゃと書くことはあったようだ。
案外そんなもんである。
今朝未明、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ツールベンダーが用意しているガードレールを活用し、プログラム作成の成功体験を与える。バイブコーディングの波に乗り、まずはとにかく完成品を積み上げること。この成功体験を通じて、ソフトウェアの作成の全体像を体感させる。これは、今までの初心者教育には出来なかったことだ。これだけでもこれまでの教育方法を刷新する価値がある。
そのうえで、標準の与えられたガードレールでは不足が生じた段階になれば、ガードレール（設計図）を自ら設計する必要性を気づかせる。
自分でガードレールを引くためには、結局のところ、コンピュータがどう動くかという基礎的な理解が欠かせない。C言語やPythonの初歩を教える意味は、実装力を養うためではなく、AIに与える指示の妥当性を判断し、構造を破綻させないための「鑑識眼」を養うことに集約される。教育を否定するのではなく、出口を「設計」へとシフトさせる。それが私の考える、新しい時代の初等教育の姿だ。
では、書けない技術者についてどう考えるのか。これは作成のレイヤーが変わったと捉えるしかないのだろう。我々だってアセンブラは書けないのだから。
おはようございます。
結局、Claude Sonnet5は来ませんでしたね。夜中に起きた時にチェックしてみたんですが、Xのトレンドに上がってなくてがっかりしました。
昨日は年度末特有のドタバタでした。プログラムについてはほんの少ししか触ることができず、残念でした。
私はClaudeCodeを使ってプログラムを作成していますが、自分のプロジェクトに限って言えば、ここ数ヶ月まともにソースコードを見たことすらありません。LAMによるガードレールを作り、テスト計画を立て、リファクタリングや実際の使用してのユーザーテストなどをやることで、片がついてしまうからです。細かいところの最適化についてはいろいろあるんでしょうけれども、使用していての問題は特にありません。
私の場合は計画を立てたり構造を考えたりするのは好きなんですが、コーディング能力というといまいちです。なので、私の場合バイブコーディングを行うのがかなり性に合っています。今やバイブコーディングというより、何なんですかね、このプロジェクトの作り方は。実際全然コーディングしてないので、これはプロダクトと言うべきなのか何なのか。
この作り方が標準的になってくるのであれば、現在よりもコーディングの職人的なところが排除されていき、工芸品より工業的になっていくのではないかと思います。大規模なプロジェクトについては作り方は知らないのですが、中規模・小規模となってくると、どうしてもメンバーの俗人性というのが反映されてしまいます。設計や指示の仕方などを統一していけば、ClaudeCodeなどのツールが一定の水準で物を作り込んでくれる。そういう風になるのではないかなと考えています。
昨日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にしても今回のリークにしてもそのマーケティングに当たるものかもしれない。
まあ何にせよ、私にできることはほんの少し待つだけだ。
早いものでもう2月である。
私は単年度契約の講師がメインの収入なのであるが、来年度はかなり授業が減りそうなのである。ここ数年はほぼ講師の収入に頼っていたため、非常に不安を覚えている。
性格的に営業ができる人間ではない。どうしたらよいかAIに相談などもしてみるのだが、これといったいい手が見つからない。
その中にはudemyやココナラなどで講師としての腕を使い、動画などを公開してはどうかというのもあった。なかなか気が進まないのがこれも一つの手段として考えておくべきだろう。
もう一つ考えているソフトウェアの作成。AIを使っていろんな人がより簡単にソフトウェアを作ることができるようになったが、一定以上の完成度を保つためには、やはりプログラミングの知識、広範な設計の知識が必要だ。一応自分も講師以外でもいくらか普通のプログラムを作ったことがある。それで何かできないかと考えているのがもう一つだ。
例年2月3月4月は授業がないため耐える時期なのであるが、なんとかしてこの間にものになるものを一つでも作っておきたい。月に2、3万でもだいぶ違う。3、4万、できれば5万などと、取らぬ狸の皮算用を考えているのだが、果たしてどうなるやら。
