ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

Block の "From Hierarchy to Intelligence" 読んだ

Block の "From Hierarchy to Intelligence" がおもしろかった

deeeet さんが紹介してくれたやつ

From Hierarchy to Intelligence - Block

Block（Square / Cash App の親会社）と Sequoia Capital の共同論文で、AI 時代に組織構造そのものを再設計するという話。

ざっくり内容

2000年間、組織が階層型だったのは「それがベストだから」ではなく、人間の情報処理能力に限界があったから。1人の指揮官が管理できるのは3〜8人。この制約がローマ軍から現代企業までずっと生きている。

AI でその制約がなくなるなら、組織構造も変わるよね、という話。

Block は4層構造を提案している。

層 役割
Primitive Layer 決済・融資・カード発行など金融の原子的要素
World Model 社内情報＋顧客データから構築される因果・予測モデル
Intelligence Layer 顧客の状況を認識し、複数機能を組み合わせてソリューション生成
Interface Layer Cash App / Square 等の配信面

ポイントは、中間管理職が担っていた情報流通・調整の役割を World Model と Intelligence Layer が代替するということ。マネージャーの仕事を分解すると、大半は情報の中継と調整であり、それは AI でできる。人間に残るのは育成・実装・課題推進。

その結果、人の役割は3つに再編される。

人の役割は3つに再編される。

  • IC: 手を動かす人。World Model から直接コンテキストを取れるので上司の指示待ち不要
  • DRI (Direct Responsible Individual): 特定課題の責任者。チーム固定ではなく課題固定。横断的にリソースを引く
  • Player-Coach: 手も動かすし人も育てる。調整は AI に任せて職人技と育成に集中

before / after をまとめるとこんな感じ

従来の機能 before after 区分
全社の状況を把握・統合 VP / 部長 World Model 🤖
経営方針を現場に伝える マネージャー World Model 🤖
現場の状況を経営に上げる マネージャー World Model 🤖
IC に判断の文脈を与える マネージャー World Model 🤖
ステータス会議・進捗管理 マネージャー World Model 🤖
顧客状況に応じた提案設計 PM + 営業 Intelligence Layer 🤖
基盤サービスの運用 インフラチーム Primitive Layer 🤖
チーム間の優先順位調整 マネージャー同士 Intelligence Layer + DRI 🤖+👤
ユーザーへの価値配信 プロダクトチーム Interface Layer 🤖+👤
リソース配分・アサイン マネージャー DRI 👤
特定課題の推進・完遂 PjM DRI 👤
技術指導・人材育成 マネージャー / TL Player-Coach 👤
専門領域の実装・構築 IC IC 👤

思ったこと

自分はこれまで IC → GM → 部長 → VP とやってきた。「情報流通と調整」の比重はGM より部長のほうが増える。VP だと重要な意思決定とか大方針の割合が増えるが、それも自ら World model を構築して実現している感覚はある。色んな人と会話したりレポーティングを受けて、World Model を構築し、Inteligence Layer である打ち手案を検討したり試したり振り返ったりしている、と言える。

今は VP で「意思決定に集中する」ことをやろうとしているが、実際は意思決定に必要な情報を集めるコストがかなり大きい。World Model がそれを代替するなら、意思決定の純度が上がる。そして、その状態を VP だけの特権にせず現場の DRI や IC まで広げるという話だと思う。

この言語化はありがたい。あと、そこまで外れていないだろうなという感覚もある。自分は実際に個人開発では Claude Code で Director/Worker 構成を組んでいて、AI Agent が全セッションの状況を統合して報告してくれるので、自分は判断だけすればいい状態に近づいている。小さいスケールだが、World Model 的な体験をしている実感がある。

情報が階層を経由しないと届かない時代は、意思決定できるのは上位層だけだった。AI が情報をフラットにするなら、委譲のコストが劇的に下がる。マネジメントをやってきて、AI も触ってきたからこそ、この記事の言っていることが肌感覚でわかるので面白かったし、今後の時代がどうなるかも読んでいく必要があるなーと感じた。

AI Agent Manager と仕事をする

AI Agent Manager と仕事をする

昔いろいろおもしろ動画でみた気がするが、Coding Agent 同士を通信させるとか、AI Agent を束ねる AI Manager がいて数十人の部下を動かしているとかとか。。。そういうのはやったよね。今それをやっている。

多分技術的には当時と同じだと思う。あんまり新しいことはない。ただ、Claude Code の remote-control と、SKILL、そして Agent そのものの賢さがあがったこともあり格段にやりやすくなったので今やってみたらそこそこワークしている。

環境

自宅の Mac Studio 上ですべてが動いている。

Mac Studio 上で Zellij のセッションが複数立ち上がっていて、それぞれに Claude Code が動いている。AI Manager もその中の 1 セッションで、他のセッションに指示を出す。外出先からはスマホアプリ(remote control)から AI Manager に話しかけるだけでいい。「状況どう？」って聞くと全セッションの進捗をまとめて報告してくれる。便利。

技術的にやっていること

正直、技術的にはそんなに大したことはやっていない。

  • Zellij: ターミナルマルチプレクサ。tmux でもいいけど Zellij を使っている。各セッションが独立したターミナルで、それぞれ Claude Code が動いている。Zellij のほうがやりたいことがすぐやれるので普通に使う場合も馴染みやすかった。
  • agents-manager: Go で書いた薄いラッパー CLI。Zellij のセッションに対してキーストロークを送ったり、Claude Code のセッションログ（JSONL）を読んで最新の応答を取得したりする
  • Claude Code の SKILL: AI Manager の振る舞いを定義するプロンプト群。「定期的にセッション一覧を確認して報告しろ」「タスクが完了したセッションには次の仕事を提案しろ」みたいなルールを書いている
  • git worktree: 同じリポジトリで複数ブランチの作業を並列に走らせるために使っている

つまり構成要素は全部既存のもので、新しいものは何もない。Claude Code の write-chars アクション（Zellij にキーストロークを送る）でセッション間通信をしているだけ。

agents-manager（Go CLI）

agents-manager はセッション管理の道具箱みたいなもので、以下のコマンドがある。

やることはシンプルで、

  • list で「今どのセッションが生きてるか」を見る
  • read で「あのセッション何してる？」を確認する
  • send で「これやっといて」と指示を送る
  • spawn で新しいセッションを立ち上げる
  • kill で終わったセッションを片付ける

これだけ。CLI は意図的に薄く・単純にしている。

仕組み

send の仕組みを例にすると、やっていることは本当にシンプルで：

  1. Zellij の write-chars アクションでテキストを打ち込む（人間がキーボードで打つのと同じ）
  2. Claude Code のセッションログ（~/.claude/projects/ 以下の JSONL ファイル）を poll する
  3. ファイルサイズが増えて、最終ロールが assistant になったら「返事が来た」と判断
  4. 応答を出力して終了

書いてみても特に普通の話である。

SKILL との棲み分け

最初悩みながら走り出したのが、CLI と SKILL の役割分担。今の AI は十分に賢いので、ツール（スクリプト。決定的な操作）と指示に分ける感じ。

CLI（agents-manager）がやること: - セッションの一覧取得 - セッションへのキーストローク送信 - セッションログの読み取り - セッションの起動・終了 - Rate limit の確認

SKILL がやること: - 「15分おきに全セッションの状態を確認して報告しろ」 - 「作業が完了したセッションには次のタスクを提案しろ」 - 「破壊的な操作は必ず承認を取れ」 - 「放置されているセッションがあったら原因を聞き出せ」

SKILL というかたまりで AI への指示を再現性高くできるようになって便利になった。

SKILL の例：status

こっちからつっつかなくても勝手に動いてほしい。AI Manager の session 自体にも外部から指示を送ることで、15分ごとにポーリングさせることができる。

新規のタスクを指示するか、状況をみて承認するか、追加の指示をするかって感じ。「承認します。」って言ってる。これが Senior Approve Engineer である（社内で流行った）

おしまい

便利

Vice President (of Engineering) をやる

今日人事で公開された。

所属組織の組織階層は GM (Group Manager), 部長, VP, 統括VP, 役員となっていて、これまでは部長をやっていた。Manager of Manager であり、規模的には1つの領域の VPoE とも言えるだろう。そういうつもりでやっていた。

教育領域の開発統括責任者であり、開発領域はもちろん、事業/組織/プロダクト、主語を大きくして全てをなんとかしていきます。

というわけで元気です。飲みに行きましょう！

島本理生 - 一撃のお姫さま（ネタバレ）

読んだ。

一撃のお姫さま (文春e-book)

一撃のお姫さま (文春e-book)

Amazon

久しぶりに小説読んだ。島本さんの作品はほぼ全部持っている、読んでいる。高校生の時にナラタージュを読んで以来...

で、結構前だが読んでない新作がこれと、「天使は見えないから、描かない」が出ていたので買って。本作は先週の宮古島の飛行機で読んで超面白くて一気に読んでしまった。

停止する春

ダメージが蓄積してもそれに気づかないまま日常を送り続けても、それは蓄積し続けているだけで、それが一気に崩壊したように思えた。同僚であり不倫相手との話、その人と仕事を続けなければならないこと、家族のこと。そういう精神状態での食欲とか欲しがるものの描写がリアルだった。その中で駆けつけてくれたさおりちゃんが救いだ。

「黙祷がはじまらなかった」ことは、世の中が変化していくこと、悲しみや辛さが風化していくのか、それとも残っていくのか、そういう人間の捉え方を表現しているのだと思った。

最悪よりは平凡

おかしな家族と同僚、魔美という自分の名前に貼られるレッテル。そういうものに振り回されながらも半ば諦めつつ自分を持っている主人公が好印象だった。その自分を保つのが自分1人で自分を見つめ合う、決まったラーメン屋での時間だし、そこを共感できた上司の存在は偶然だとしても、邪魔されたくない気持ちもありつつ、良かったんだと思った。

バーテンダーの石田くんとの関係の薄さがあっけらかんすぎて、でもその経験が家族に対してもこれからの未来についても吹っ切れるきっかけになっていて、衝撃みたいなものは時に人生を前に進めるためにはあっても良いものかもな、と思った。死なない程度に。

God Breath You

生活が見えて好きな作品だった。大学の准教授。交際する若い時生くんとの年齢差の話が心が痛かった。学生との進路相談の話でSNSに書かれていたのは妙にリアルで面白かった。

家出の庭

一番好きかも！家の外でキャンプをする義母。発達障害だろうがなんだろうが、そんなものに名前がつくようになって、「変」だとみられるようになったって、人間の心の温かさみたいなものを差別される筋合いはない。家で場所がみんなあるといい。義母の温かさが良かった。

一撃のお姫さま

自分が音楽好きなのもあって、音楽制作の話も面白いし、ホストクラブの世界も（自分が行ったことない分）面白かった。そして創作というものが日常や思考に影響されることにも自分が以前創作していたことを思い出して共感した。創作をしたくなった。

ヨルシカを想像しながら（主人公は女性ではあったが）読んでいた。

作品の世界観を表現する作品作り、なんて素晴らしく美しい職業なんだろう。憧れる。

島本さんの作品に共通する夜、お酒、美味しいご飯。人間の感情。生活。どれも雰囲気が好き。

自宅でもノートPCでもスマホでも同一 AI Agent セッションを使いまわしたく tmux を試すも微妙

微妙なんです。

はい、1月はブログなるべく毎日書きます。

解決したい課題

  • 自宅には Mac Studio があり、つけっぱなしである。スペックも高く、家では基本これを使う
  • 出先では Mac Book Air を使う
  • codex (AI Agent) の作業セッションは Mac Studio と Mac Book Air で引き継げないのが面倒であった
    • branch push して PR にしておけば続けられるとはいえ
  • あと、特に Mac Book Air で作業しているときに、PC を閉じると AI Agent の作業が止まる勿体無さもあった
    • どんだけやねんって話はあるけど、ねぇ
  • 1つの作業単位（worktree）単位で複数ウインドウを開き、codex とテストしたりコマンドしたりサーバ立ち上げたりしたい

どうする

  • 常時起動している Mac Studio を母体とし、Tailscale network を使ってアクセスし、ssh 経由でアクセスする
  • 作業単位は元々自作ツール chaspy/workbloom で git worktree 単位で作業をしていた。
    • そこで、今回は git worktree と tmux session を 1:1 とすることにした
  • ssh する以上、毎回 shell session が新規で作られてしまうため、それに相当するセッションを mac studio 側で持つ必要があり、tmux を採用した
  • スマホからの ssh はとりあえず Termius で繋がった

nano banana が書いてくれた絵は可愛い

結果: そもそも tmux 面倒

  • そもそもキーバインドのデフォルトがだるい。Ctrl + b であり、それプラス別コマンド
  • Pane を分けるにしても、iTerm2 / Ghostty のようなターミナルで分割したものを行き来するより操作が若干だるい
  • 上にスクロールするにもいちいち Ctrl + b & [ はだるすぎる、さっと上見たいだけなんだが
  • tmux のセッションを操作して attach するのは zshrc にエイリアス書いたので、これ自体は楽にできる
  • tmux のキーバインド変えればいいでしょはそう、そうなんだけど、なんかなあ

今後どうするか

  • tmux が絶対必要なのかでいうと、どうなんだろう
    • リモート(mac studio) 側で（特にcodexが）動いているセッションに別の端末から繋ごうとすると、どうしても同等のソリューションは必要になりそう
    • それが tmux かは検討の余地があるか

みんなどうしてます？

か？ そんなに AI 依存してないですか、そうですよね...

サウンドバー Denon DHT-S218K を買った

イェーイ

（線が気になるのはそのうちどうにかされるはず）

背景と解決したかった課題

  • テレビは REGZA の 55インチのものを壁にかけていて、本体のスピーカーだが、どうも音声が聞き取りづらい
    • おそらく僕の耳が妻より悪い
    • しかしボリュームを上げようとすると全体が上がってしまい、セリフが聞き取れる量だと背景の音声も上がり、そうすると妻が辛い
    • テレビの設定で音声クリアモード的なものも試して、多少マシにはなったが、効果は限定的
  • テレビの 2m 前ぐらいにリビングがあり、そこからやや斜めに 1.5m ほど離れたところにダイニングがあり、そこで食事しながら見ることもあり、距離も若干ある

いろいろ調べた結果、初手サウンドバーがいいのでは、となり、調査し、あれよと購入

比較した

他のメーカーともいろいろ比較したが、コスパが良いというのと、実際の音を店頭で試せたのが決め手であった。

同じ Denon であれば S517 サブウーファー付きのと迷ったが、正直サブウーハーが自分たちに必要かもわからなかったのと、一体型が割と新型であること、繰り返すが店頭で十分満足できそうだった（映画的なブォンっていう低音の迫力も感じられた）ので、初手はここからエントリーで試し、1、2年で満足いかなければさらなる高みへ、でいいのでは、となった。

www.biccamera.com

ビックカメラのこの製品で、ポイント相殺を考えると Amazon とほぼ同じ、で、じゃあすぐ持って帰りたいし、日本企業応援したいし（？）で買ったらさらに謎割引がかかって結果的にさらに安くなった。ありがとうありがとう。ということでビッグカメラ新宿店で買うのをお勧めします。

結果

良い。満足。

昨夜も2人でラブ上等を見たが、ボリュームを従来より上げずに十分クリアに聞き取れる。夫婦で楽しめて生活の満足度アップである。音楽でも漫才でもドラマでもなんでも良い感じ。よかった。

それはそうとラブ上等はめちゃくちゃ面白い。「ヤラセだと思って見ても面白い」と妻の友人に聞いて見始めたがマジで面白い。いわゆる恋愛リアリティーショーであるが、一線を画す面白さである。

www.netflix.com

「エンジニアのための生成AI入門」を発売しました

出ました！12/22 発売してました！担当編集のないとうさん、ソシム出版の皆さん、共著者のお二人、レビューくださった三人、読んでくださったみなさん本当にありがとうございます！

エンジニアのための生成AI入門 はじめての生成AIアプリ開発からエージェント開発まで

エンジニアのための生成AI入門 はじめての生成AIアプリ開発からエージェント開発まで

Amazon

きっかけ

2025年3月13日に、同僚でもある高橋あおいさんから「こんにちは〜！私と共著で生成AIに関する本書くことに興味ありますか？」ときて、「よさそう、ぜひ！」と即レスしていた様子が発見されました。

その後5月ぐらいまで打ち合わせをして企画自体が進み、6/10あたりに見本原稿として、どこかの章を試しに書いてみる、というステップを踏みました。9/26（金）に初稿が終わり、そこから校閲〜直しというのを11月の後半までやっており、かなりギリギリというか、こんな時期まで変更しててええんやな...!? みたいな感覚でした。（現代の出版印刷のロジがすごいという話かもしれないが）

と執筆期間自体はそれなりではあるものの、実際はガッと書き進める時期とそうでない時期があった感覚でした。

担当章

どうやって担当が決まったかあんまり覚えてないですが（記憶がなさすぎる）自分は2章のプロンプトエンジニアリング、5章の RAG、7章のエージェント開発を担当しました。

どこもそれなりに産みの苦しみがあったんですが、特に2章のプロンプトエンジニアリング自体は、 reasoning model が十分成熟したことがあり、あるあるのテクニックは内部的に実践してたりして、実際に API 経由で試した時にこれって書籍として学びがあるのか？という葛藤と、生成AIの進化の速さ)を痛感しました。

とはいえ、章末に書いたんですが、プロンプトエンジニアリング自体が基礎の基礎であることは間違いなく、今後モデルによって隠蔽されようとも内部ではやっていることではあるため、知っておくこと自体は有益だと思っています。

5章の RAG もこれまた別にローカルで自前で作らなくたっていくらでもマネージドなソリューションはあるわけです。NotebookLM とか AWS Bedrock Knowledge base とか。なんですけど、この本はエンジニア向けがもし自社でマネージドを含めて RAG を構築する際に、トラブルシューティングをする際には基礎的な仕組み自体をほんの少しでも触れておくほうが有益だろうなという思いもありました。なるべくお金がかからないようにしたというのもある。

7章のエージェントは割と締め切り近い段階でアサインが決まりw 書き上げたんですが、1番苦労しました。AI エージェントの名前自体はかなりよく聞くようになりましたし、専門の本もいろいろ出てきました。とはいえ本書では基礎から積み上げた最後というところで、既存の技術を意識しながらどういう積み上げて成り立っているのかを意識して書いたつもりです。意外と単純だな・シンプルだな（実際はそうではない）と思えたら嬉しいです。実際に運用する難しさはもちろんあるのですが、全く謎のものではない、と思ってもらえるんじゃないかしら。

書いてみての感想

SRE の知識地図もそうなんですが、担当編集さんには頭が上がりません、本当にいろいろわがままも言ってしまい、また書籍の細部にあたり表現について気遣い、提案いただき、（ないとうさん以外にも関係された方はいらっしゃると思います）本当にありがとうございます。編集者さんすごいで...

あと、自分自身意外だったのが、もしかして結構需要あるのかもな、と書き上げて気づいたというか。自分自身は3月頃から LLM API を呼んでなんらかの自動化はしてましたし、RAG のソリューションも社内で提供していたりしました。その後エージェントもローカルで開発してたので、自分の中ではそこそこ触れていたこともあり、「本当に需要あるのかしら...」という不安もなくはなかったです。

でも本屋さんでみてみると、意外とエンジニア向け（開発者向け）かつ、入門からエージェントまでの本はそんなにないな、ということと、周囲を見て感想を聞いても、意外とそんなに触ってないという人は多く、キャッチアップはしておきたい、みたいな需要にも応えられたのかなという実感もあります。編集者さんの企画力の高さにここでも驚きでした。すげえ。

著書の「おわりに」を引用します！

一部抜粋にしようと思ってたんですが良いこと書いてるので全部引用します！w

皆さん、最後まで読んでいただきありがとうございました。

読み進めながら「何を言っているのかわからない」と思うことや「さっきのものとどう違うの？」と疑問を持ったこともあったかと思います。しかし、ここまで読み進められたあなたは、きっと生成AIは”特別なもの”とは感じていないはずです。

実際に手を動かしてみると「意外と動くんだな…？」とか「動いたらちょっと楽しいぞ？」みたいな気づきもあったのではないでしょうか。個人的に、生成AIは”触ってみないと距離が縮まらないタイプ”の技術だと思っているので、その距離が少しでも近づいていたら嬉しいです。

著者の高橋あおいさんのイラストや漫画も、まさにその“とっつきにくさ”を減らすための工夫として描いていただいています。皆さんが一度は思ったことがあるだろうことを、キャラクターたちが悩んだり落ち込んだり元気になったりと、見ていて元気がもらえます。ソースコードと文章だけだと腰が重くなるところを、少しは読んでみようかな、と思える空気にしてくれてます。

今後も生成AIの世界は今まで以上に新しいものも出てくるでしょう。ツールやライブラリの細かい仕様は今後も容赦なく変わっていくはずです。でも、本書で扱った「考え方」や「組み立て方」は、けっこう息が長いはず...と思って書いています。そしてこのような書籍を通じて、皆さんが”新しいものの学び方そのもの”を身につけてもらえたなら、それが何よりです。

それでは、これからの皆さんの学びが、楽しく前向きなものであることを願っています。

著者を代表して 近藤健司

おわりに＆感想の紹介

というわけで年始のお供に！どうぞ！よろしくお願いします！読んで X や社内で広めてください！

読んでいただいた方はありがとうございます！見つけた限りで貼ります〜〜〜！

Blog

ありがとうございます！！！！！！！

note.com

X

みのるんさんレビューありがとうございました！

たけやまさんレビューありがとうございました！

おまけ：書店巡り

イェーイ

置いていただいた皆様、本当にありがとうございます！