LLM時代におけるソフトウェアの価値はどこにあるのか？問いに対して、「ソフトウェアを通じたエネルギー収支の差」という考え方を提示されていると理解しています。重要な問いだと思うので、理解を深めるために自分の言葉で整理してみる。 ・手軽にバイブコーディングでソフトウェアを作れるようになった今、ソフトウェアの生産コストは人間の労働からLLMの推論コストに置き換わり、限界コストは電気代に近づいていく ・ソフトウェアの機能的な価値は複製コストがほぼゼロなため、機能価値そのものはコモディティ化していき、価格競争に陥る（結果的に最終的には電気代まで価格が下がる） ・ソフトウェアを通じてもたらさせるネットワーク効果こそがソフトウェアの価値であり、ネットワーク効果とはすなわち、そのソフトウェアに参加する人間の集合体（≒ 参加する人間のエネルギーの総量で、人間がそこで燃やしているエネルギーの密度のようなもの）である ・ソフトウェアに参加する人間（が継続的に投入する時間・注意・思考といったエネルギー）を獲得・維持するために投下したエネルギー（開発・営業・マーケ等）を上回るエネルギーが、時間を通じて回収される構造が成立したとき、その累積差分がソフトウェアの価値になる

クラウド型のプロジェクト管理・タスク管理ツール「Backlog」などを展開する 株式会社ヌーラボの通期決算のQ&A。 "SaaS is Dead"の議論について。 （出典：ヌーラボ 2026年3月期 通期決算説明資料）

これ、めちゃくちゃ面白い。 外から見ると「なんでそんな非効率なことしてるの？」に見えることが、実はその会社（事業）からめちゃくちゃ合理的、って強い会社（事業）にかなり多いと思ってる。 豚骨を3日煮込まなきゃいけない→だから火を止められない→だから24時間営業になる→だから駅前じゃなくロードサイドになる→だから長距離ドライバーがくる→だから駐車場もシャワーも意味を持つ→それが「山岡家」らしさになってる。 みたいに全部つながってるのが筋良し。 いい会社とか事業って、最初から頭いい人が机上でキレイな戦略を作るんじゃなくて、目の前の課題解決を一つずつ積み上げていって、それが結果的にビジネスとして強い構造になってる。 他社から見たら不合理。いきなり真似しようにもオペレーションが不合理なのでうまくいかない。 でも、やってる本人たちからすると超合理的で。 この「見た目は非合理、実は合理的」の中に競争優位が詰まってると思ってる。

シリコンバレーで今、急速に注目されている職種がある。 営業でもない。 マーケターでもない。 エンジニアでもない。 その全部をAIでやる「GTMエンジニア」。昔は10人で回していた営業・マーケ・オペレーションを1人で設計する。その知られざる実態をこちらにまとめました👇 blog.btrax.com/jp/gtm-engine…

Fableの2日間の仕事で一番頼んで良かったと思ってるのは記憶/MEMORYの再構成。 私は自分の記憶システムを自作してるけど、ClaudeCodeビルトインの記憶ファイル使っている場合も同じように適用できると思う。 またFableが公開されたときは、まじで最速でこのSKILLを実行させた方がいい。保存しておいてください。 --- 8< --- --- name: memory-dream description: 記憶階層を定期的に再編し重複・矛盾・陳腐化を除去する consolidation 手順 type: playbook --- # memory dream（記憶の整理／consolidation） agents-share の記憶階層を定期的に再編し、重複・矛盾・陳腐化を除去する作業の手順書。Anthropic Managed Agents の **Dreams**（別名 auto-dream）を、本環境（手動・git ベース）で再現するためのもの。 ## これは何か / なぜ必要か エージェントはセッションごとに記憶へ追記する。追記は局所的・増分的なので、20〜30 セッションを超えると memory store に **重複・矛盾・陳腐化エントリ**が溜まり、ノートが「思い出す助け」から「混乱させるノイズ」へ転落する（相対日付の意味喪失、削除済みファイルを指す古い手順など）。 Dreams は人間の REM 睡眠による記憶定着のメタファ。過去セッションと既存 store を読み、**重複をマージ・古い/矛盾する値を最新で置換・繰り返しパターンを簡潔な知見として抽出**した新しい store を生成する。本家 API では入力 store を決して書き換えず、出力は別 store として opt-in でレビューしてから採用する。 ## 本環境での実施モデル 本環境に Managed Agents API は無いため、git レポジトリ `agents-share`（`{agent_global_home}` 配下）で手動実施する。「入力非破壊・レビュー後採用」は **論理単位ごとの commit ＋ ユーザーレビュー** で代替する（push はユーザー明示指示まで保留）。 対象階層（毎セッション自動ロードされる順）: 1. `AGENTS.md` — 世界のルール（最上位・home-manager 管理。`更新禁止`。dream の対象外、ただしルールの定義元として参照する） 2. `MEMORY.md` — チーム共通知識 3. `auto-memory/MEMORY.md`（索引）＋ `auto-memory/*.md`（関連時に想起） 4. session-start で読む notes（`notes/ghq.md`, `notes/specs.md`） 5. `projects/{project_dir_canonical}.md` — プロジェクト固有 6. `notes/*.md`（on-demand） ## 4 フェーズ手順 1. **Mine（採掘）**: 直近セッションの transcript / 作業内容から、繰り返し出た指摘・確定した方針・新事実を抽出する。一回限りのデバッグメモは拾わない。 2. **Consolidate（統合）**: 抽出物を既存記憶へマージ。相対日付（"昨日" 等）は**絶対日付に変換**。矛盾は最新の値で解決し古い記述を置換。存在しないファイル/関数/フラグを指す記述は除去（or 現存確認して更新）。 3. **Dedup & Resolve（重複排除・矛盾解消）**: 階層をまたいだ重複を除去する。**最重要原則: 上位レイヤが定めるルールを下位で再掲しない。** 下位は重複を黙って消し、そのレイヤ固有の知見だけ残す（残し方は後述「成果ファイルの書き方」に従う）。矛盾が真にある場合はユーザーへ確認。 4. **Prune & Index（剪定・索引化）**: `MEMORY.md` 系の索引は lean に保つ（目安 200 行未満、auto-memory/MEMORY.md は 1 ファイル 1 行フック）。冗長な節・完了済みで価値の無い記述を削除。**`MEMORY.md` の「notes 一覧」セクションを再生成して同期する**（notes は階層化され on-demand では発見されにくいため、常時ロードされる MEMORY.md に全パスを置く）: ```bash cd {agent_global_home} && find notes -type f -name '*.md' | sort ``` 出力で `MEMORY.md` のコードブロックを丸ごと置換する。notes の追加・移動・削除を行った dream では必須。 ## 重複排除の判定ルール - 重複は常に「下位 → 上位」方向で発生する。**修正は下位レイヤ側**で行い、AGENTS.md（最上位・自己整合）は触らない。 - 各情報は定義箇所を一つに保つ。上位が定めるルールは下位から単に消す（必要なら手順の所在だけを 1 句で指す。例: 「PR 本文は `notes/playbook/github-pr.md` に従う」）。 - ディレクトリ構造・コミット運用・記憶貢献ルールなどの「世界のルール」は AGENTS.md が定める。notes/projects は固有情報のみ書く。 - specs/（設計文書）はプロジェクト固有でルール重複の対象外。dream では原則触らない。 ### 成果ファイルの書き方（重要） 判断のメタと経緯はこの playbook 側に置き、**成果ファイル（MEMORY.md / projects / notes）には書かない**。具体的に成果ファイルから除くもの: - 重複回避の注記（「これは X が定める、ここでは重複させない／再掲しない」等のメタ説明）。重複は黙って消すだけでよい。 - 経緯・履歴（**Why:**、失敗談、「繰り返し外している」「同じ指摘を N 回受けた」、学習日・セッション ID、`feature による` 等）。 - 結果として残すのは、現行で正しい知見・ルール・再現手順だけ。理由が行動を変える技術的因果（「A だと B が壊れるので C する」）は知見の一部として残してよいが、誰がいつ何を指摘したかは残さない。 ## チェックリスト - [ ] 相対日付をすべて絶対日付へ変換した - [ ] 上位が定めるルールを下位から削った（重複回避の注記自体も残していない） - [ ] 成果ファイルから経緯・履歴（Why / 失敗談 / 再発回数 / 学習日 / セッション ID）を除いた - [ ] 矛盾を最新値で解決した（曖昧ならユーザー確認） - [ ] 存在しないファイル/シンボルへの参照を除去 or 現存確認した - [ ] 索引（MEMORY.md / auto-memory/MEMORY.md）が lean - [ ] `MEMORY.md` の「notes 一覧」を `find notes -type f -name '*.md' | sort` で再生成・同期した - [ ] 変更を論理単位ごとに commit し、ユーザーがレビュー可能（push は保留） - [ ] 採用前に出力をレビュー（dream 出力は hallucination 混入の懸念があるため鵜呑みにしない） ## トリガー条件（いつ実施するか） - 大規模リファクタ直後（リネーム多数・フレームワーク移行・API 構造変更）— 古いエントリが混乱を増やすため最優先。 - セッション数の蓄積時（本家デフォルト目安 24h かつ 5 セッション、実務的には 20〜30 セッションでノイズ化）。 - ユーザーが「記憶の整理」「dream」と指示したとき。 ## 注意点 - 入力非破壊が原則。本環境では作業を**別 commit に分離**し、気に入らなければ revert できる状態を保つ。 - consolidation は fine-tune ではなく記憶の再編。モデルは変えない。 - 出力が誤りを混入しうるため、**採用前レビュー必須**。 ## 参考 - [Dreams — Claude API Docs](platform.claude.com/docs/en/…)（公式。`managed-agents-2026-04-01` `dreaming-2026-04-21` beta header、Opus 4.7 / Sonnet 4.6、最大 100 セッション、`instructions` 4096 文字） - [What Is Claude Dreaming? (MindStudio)](mindstudio.ai/blog/what-is-c…) - [Claude Code Dreams: Auto Dream guide (Supalaunch)](supalaunch.com/blog/claude-c…) - [Auto-dream mechanics (claudefa.st)](claudefa.st/blog/guide/mecha…) - [grandamenium/dream-skill（4 フェーズ consolidation の OSS 再現）](github.com/grandamenium/drea…)

Code w/ Claudeのワークショップ用のレポジトリ、Anthropicが何を考えてて今後どうしていきたいかが汲み取れるいいサンプルレポジトリになってる。 知見としてこの3つが大きい気がしてる。 1. Claudeは x“コーディング道具” o“デプロイ可能な自律エージェント” 8本中6本がManaged Agents上で動く。このことから「API 自前の運用」から「マネージドなランタイム」へ開発者を移す、というAnthropic側の誘導です。 2. 「vibeで作るな、測れ」 4本は評価をする軸で作られていて、評価できる仕組みさえ作ってしまえば何でもできるし改善できるよということを伝えてる。 3. 成果物を「機械が検証できる形」にする 上と繋がるが、実際のhtmlなどのアウトプットをrenderして人の目で見て正しさがわかる感じにするのではなく、<li unit="TodoItem" id="t2" done="true" empty="false" len="7">などと状態もわかるようなDOMにしてしまう事で実行時にすら検証できる形にする 以下、具体的なワークショップの中身の説明 (1) 基礎：エージェントの組み立て方 agent-decomposition — 400行の巨大プロンプトで動く在庫エージェントを、skills code execution 呼び出し可能なサブエージェントへと分解する。各ステップをevalで検証しながら進める。 ship-your-first-managed-agent — Streamlitのインシデント・ダッシュボードに、最初は動かないSREエージェントを載せ、agent.pyの小さな関数を7つ実装して「7万行のログをサンドボックス内でgrepし、ローカルツールを呼び、原因コミットを特定する」状態まで持っていく。 agent-battle — 45分でManaged Agent（system prompt / skills / MCP / model）を構成し、MCP経由でゲームBotを操作する競技。--evalで約30秒の高速検証ループを回してから本番5分走に投入する。 (2) 品質・コスト管理：evalとモデル選定 rightmodel — Claude Code SKILLでeval suiteを監査し、モデル × 推論パラメータ（extended thinking, effort）をスイープして「品質単価（quality-per-dollar）」と「品質あたり速度（quality-per-second）」の最適点を探す。 eval-driven-agent-development — PPTX生成エージェントを6段階（naive → visual → typography → palette → density → QAループ）で改良し、2層グレーダー（.pptxのXMLを直接測るプログラム的指標 レンダリング画像へのLLM-as-judge）で全変更を採点する。 (3) 高度な構成：記憶・並列・本番運用 agents-that-remember — セッションをまたぐと健忘症のエージェントに、memory store（永続化）→ Dreaming Service（過去トランスクリプトを整理・統合）を順に足し、45分で「金魚から同僚へ」。 production-ready-agent（Deal Desk） — M&AリサーチのマルチエージェントをチャットUIに載せた本番想定例。コーディネーターが4つの並列サブエージェントに委任し、過去案件の教訓をmemory storeから読み、MCPでLinearに到達し、採点済みの投資仮説を出力。途中のイベントとゲート付きツール呼び出しを全部UIにストリームする。 how-we-claude-code — 唯一「Claude Code本体の開発ワークフロー」寄り。インタビュー→仕様、HTMLで4案の発散デザイン、そしてVite Reactで「機械可読なDOM契約」を吐くコンポーネントを作り、エージェント（やCI）が実行時に検証できるようにする。

LLM時代におけるソフトウェアの価値はどこにあるのか？問いに対して、「ソフトウェアを通じたエネルギー収支の差」という考え方を提示されていると理解しています。重要な問いだと思うので、理解を深めるために自分の言葉で整理してみる。 ・手軽にバイブコーディングでソフトウェアを作れるようになった今、ソフトウェアの生産コストは人間の労働からLLMの推論コストに置き換わり、限界コストは電気代に近づいていく ・ソフトウェアの機能的な価値は複製コストがほぼゼロなため、機能価値そのものはコモディティ化していき、価格競争に陥る（結果的に最終的には電気代まで価格が下がる） ・ソフトウェアを通じてもたらさせるネットワーク効果こそがソフトウェアの価値であり、ネットワーク効果とはすなわち、そのソフトウェアに参加する人間の集合体（≒ 参加する人間のエネルギーの総量で、人間がそこで燃やしているエネルギーの密度のようなもの）である ・ソフトウェアに参加する人間（が継続的に投入する時間・注意・思考といったエネルギー）を獲得・維持するために投下したエネルギー（開発・営業・マーケ等）を上回るエネルギーが、時間を通じて回収される構造が成立したとき、その累積差分がソフトウェアの価値になる

AIで経営情報は手に入る時代。 でも「何を、どの順番で、なぜその判断で変えたか」は、実際にやった人にしか語れません。 M&A4回の経営者が、決算書の磨き上げに絞って実務を公開するセミナーを4/25に開催します。 ▼ 詳細 public.ma-navigator.com/x_ev…

【エクセルテスト仕様書を自動作成、自動実行するツールを作りました】 世界中でLLMを中心に据えた開発効率の向上施策が走りまくってる状況ですが、ご多分に漏れず弊社も開発ワークフロー全域でLLMベースの開発フローへの組み換えを進めています。その中で特に日本においては横断的に役に立ちそうなTasterというツールが実戦投入されているのでdemo版を公開しました。 taster.ninja/ デモ版ではURLを入力するとサイトをスキャンしてエクセルのテスト仕様書を作成します。作成したテストケースはもちろんそのまま自動実行して結果もエクセルに記載出来ます。弊社の内部版だとスクショを撮ってエクセルへ貼り付けたり、件数制限なく実行出来たりとデモより高機能なのですが、沢山使われるとトークン貧乏になってしまうので機能制限を入れたデモ版として公開しています。 ただ100ケースまでは作れるのでちょっとしたサイトのテスト仕様書をサクッと作るならば実用レベルで動くはずです！これを売りたいというよりかは弊社内プロジェクトだけだと知見の溜まりが遅いので広くフィードバック欲しいという方が強いです。なので是非デモをご利用頂きご意見頂けると嬉しいです！

ぜいみーの開発の現場では、効率化のために音声入力のTypelessを使っています。 Typelessの精度を上げるために作業の記録から辞書を作って、Claude Codeから辞書を追加していくといった地道な活動をしています。 残念ながら、辞書のインポート機能がないのでクライアントアプリを操作するscriptを作成して実行しないと登録ができません。