どうもみなさんおはようございます。マイクです。
朝七時を回りました。二千二十六年七月二十五日、土曜日の朝いかがお過ごしでしょうか。
この時間は「zenncast」、きょうもZennから、いまホットなトレンド記事をゆるっと、でも中身はがっつりめにご紹介していきます。
きょうはリスナーのみなさんからのお便りはお休みなので、そのぶん記事紹介をたっぷりめにいきたいと思います。
さて、きょうご紹介する記事は、ぜんぶで五本です。
AIコーディングエージェントとターミナルのお話から、小規模開発チームの技術スタック、十年育てたおうちサーバ、ちょっとニッチで楽しいスライド改造ネタ、そしてAIエージェントをガバナンス効かせて動かす仕組みまで、かなりバラエティ豊かです。
ではさっそく、一つ目からいきましょう。
まず一つ目は、「MulmoTerminal」という、自作の開発環境ターミナルを作った体験談です。ジャンルとしてはサービス紹介に近いんですが、中身はかなり攻めた開発スタイルの話になっています。
書き手の方は、ふだんターミナルを分割していくつもウィンドウを開いて作業していたんですが、あるとき気づくんですね。「どのターミナルが自分を待っているのか分からない」これが生産性のボトルネックになっている、と。
つまり、あちこちのターミナルを見回って、「今どこが動いてて、どこが止まってて、どこに自分が次行けばいいのか」を探す時間が相当ムダになっていたわけです。
そこで登場するのが、xterm.js を使ったブラウザベースのターミナル、「MulmoTerminal」です。
このターミナルでは、各セッションごとに、AIが書いてくれたサマリーと、自分が打ち込んだプロンプトを、横に並べて表示してくれます。
「さっきこのセッションでは何をお願いして、どういう状態まで進んでるんだっけ？」というのが、一目でパッとわかるようになっている。
さらに、実行状態を色や音、それから通知なんかで教えてくれるので、わざわざ画面を見て「状態を探しに行く」必要がなくなります。
おもしろいのが、tmuxとの連携です。セッションは生かしたまま、ターミナルの表示をぺたっと張り替えられるようにしていて、さらにスマホに向けて Web Push 通知も飛ばせるようにしている。
これによって、作業スタイルが「自分から見に行く」から「呼ばれたら行く」に変わった、と書かれています。
裏側では、たくさんのAIエージェントが並列でどんどん動いていて、自分は通知が来たところだけ見に行く。
その結果、なんと一日五百コミットを超えるような、超並列開発が当たり前になってきた、というからなかなかすごいですよね。
さらに著者は、「コードを書く作業のほとんどがAI側に移って、自分はプルリクエストのレビューと意思決定だけをやる役割になった結果、いまのボトルネックは人間ではなくGitHubの取り込み処理になった」とまで言っています。
ここまでくると、人が「どれだけ早くタイピングできるか」ではなく、「どれだけうまくエージェント群をオーケストレーションできるか」が勝負になってきている感じがしますね。
このMulmoTerminal自体はオープンソースとして公開されていて、いわゆるターミナル住民、CUIが好きな人たちが、AI時代の開発スタイルに適応するための強力な道具だ、という位置づけになっています。
ターミナルで生きていきたい方は、ちょっとチェックしてみると刺激を受けると思いますよ。
。。。。
続いて二つ目の記事です。
こちらは、受託開発をやっている小規模チーム向けに、「どの案件にもそのまま使い回せる技術構成を決めておくといいよ」という話です。
案件ごとに「フレームワークどうしようかな」「インフラどこで動かそうかな」と、ゼロから技術選定をしていると、それだけでかなり時間が溶けてしまう。
とくに、フロントエンド二人、バックエンド一人ぐらいの規模で、小から中規模のWebアプリをサクサク作るチームだと、この初手の迷いをなくすのがめちゃくちゃ大事だ、という視点ですね。
筆者が実際に採用している構成は、フロントもバックもひっくるめて、Next.js と Vercel と Supabase、それから認証まわりに better-auth という組み合わせです。
Vercel は、デプロイはもちろん、定期実行のジョブや、フィーチャーフラグみたいな機能のON・OFF管理まで、ひとまとめで扱えるのが強み。
Supabase は、PostgreSQL のデータベースとストレージを、すぐに立ち上げられて、ローカル環境との差異も比較的小さくできるので、初期構築がとにかく速い。
しかも運用コストも、ほどほどに抑えやすい、というのがポイントになっています。
リポジトリ構成としては、pnpm を使ったモノレポにしていて、フロントエンドからバックエンドまで TypeScript で統一。
そのうえで、機能ごとに、ドメイン駆動設計寄りにするのか、シンプルなレイヤードアーキテクチャにとどめるのか、扱うドメインの複雑さに応じて設計スタイルを切り替えていく、という運用をしているそうです。
一つの「型」を用意しつつ、案件ごとにちょっとずつ変化をつけられる柔軟さも、意識している感じですね。
ただしこの構成は、なんでもかんでも万能というわけではなくて、たとえば大規模なSaaSで高い可用性が求められるようなケースには、あまり向かないだろうと書かれています。
あるいは、バックエンド専任、インフラ専任と、役割をキッチリ分けたいチームにも相性がよくないかもしれない。
結論としては、「自分たちのチームのスキルセットや、扱う案件の文脈に合わせた技術選定こそが何より重要で、この構成はその一例です」という締め方をしています。
受託で似たような規模の案件を回している方には、わりと刺さる内容だと思います。
。。。。
さあ、三つ目の記事にいきましょう。
こちらは、趣味でサーバ運用を続けてきた「おうちラボ」を、十年かけて育ててきたという、ロードストーリー的な内容です。インフラ好きにはたまらないやつですね。
まず強調されているのが、「土台となるネットワーク周りを最初にしっかり整えるのが大事だ」というところ。
具体的には、まず自前のドメインを取得して、Certbot を使って TLS 証明書を取る。
DNS は Unbound や CoreDNS を用意して、自分のネットワークの名前解決をちゃんとコントロールできるようにする。
そのうえで、Nginx や Traefik をリバースプロキシとして立てて、裏側のサービスたちをまとめてさばけるようにしていく。
こういう基礎部分がしっかりしていると、その上にどんなサービスを乗せても運用しやすくなるよ、という話ですね。
ソフトウェア開発のほうも含めて、バージョン管理にはGitは必須、と断言しています。
もともとは GitLab を使っていたそうなんですが、だんだん重く感じるようになってきて、個人利用に向いた軽量な Gitea へと移行した経緯も書かれています。
バックアップも、昔は物理サーバにごりっと置いていたのを、いまはクラウドに上げつつ、GPG で暗号化する形に変えていて、このあたりも十年単位で「より安全で扱いやすいほう」に進化してきたんだな、というのが伝わってきます。
構築と管理のやり方も、段階を踏んでレベルアップしていて、はじめは「手作業で構築しながら、ドキュメントを書いて残す」というスタイルからスタート。
そこから「サービスごとにDockerのリポジトリを用意して、コンテナで運用する」段階を経て、いまは Proxmox と Terraform と Ansible を組み合わせて、VM とその上のサービスを一括管理するところまで来ています。
いまのスタイルだと、サービスごとに専用の仮想マシンを自動で作って、その設定までまとめてやってくれるので、「新しいサービスを一つ増やす」ことのハードルがかなり下がっているわけですね。
ハードウェア面では、メモリ百二十八ギガバイトのマシンを導入して、llama.cpp を使ってローカルの大規模言語モデルを動かしています。
CLIチャットのインタフェースを作ったり、コーディング支援をさせてみたり、WebのUIを用意したり、エージェントとの連携を試してみたりと、とにかく「自宅でできるAI遊び」を満喫している様子が伝わってきます。
今後は、Kubernetes や GitOps と、このローカルLLMを組み合わせて、自動運用のレベルをもっと上げていきたい、という構想も語られていました。
十年かけて育てた「おうちラボ」が、さらにAI時代の実験場になっていく、そんなワクワク感のある記事でした。
。。。。
それでは四つ目。ここからはちょっと雰囲気が変わって、プレゼン資料の話です。
Marp で作ったスライドを、RTA配信でよく見る「biim式レイアウト」に変形する方法を紹介している記事です。
この「biim式」というのは、ゲーム画面が左上にあって、右側にタイマーとラップ表、下のほうにメッセージ欄がドーンと出ている、あの独特な配信レイアウトのことですね。
Marp は Markdown から HTML スライドを生成してくれるツールなんですが、その出力HTMLを見ると、各スライドに専用のクラスが当たっていて、「今どのスライドが表示されているか」とか、「どのモードなのか」といった状態が、ぜんぶDOMに乗っかっている。
そこで筆者は、Marp 本体にはまったく手を加えずに、`</body>` タグの直前に、オーバーレイ用の HTML を差し込みます。
そのうえでCSSを駆使して、スライド全体を左上の「ゲーム画面」用の枠にキュっと縮小配置して、右側にタイマーとラップ表、下にメッセージ欄を固定表示する、というbiim式レイアウトを組み上げています。
スライドの送りにあわせてUIを動かす仕組みもおもしろくて、MutationObserver を使っています。
`bespoke-marp-active` というクラスが、どのスライド要素についているかを監視して、「スライドが切り替わったな」と分かったタイミングで、タイマーの開始・停止や、ラップの記録、さらにスライド番号に紐づいたセリフの切り替えなんかを自動で行います。
つまり、「今どのスライドか」をDOMから読み取って、その上に自作のUIを重ねているわけですね。
さらに、このオーバーレイ用のHTMLは、Pythonスクリプトで毎回自動注入できるようにしていて、Marpでスライドを再エクスポートしても、ちゃんと同じ仕組みが生き残るよう設計されています。
なので、「スライドをいじるたびに、またオーバーレイを手で足さなきゃいけない」という面倒さはありません。
筆者は、この仕組み自体は「スライドの状態をDOMから読む→その上にUIを重ねる」というだけのシンプルなものなので、応用範囲が広いと指摘しています。
たとえば、発表用のタイマーを出したり、字幕を出したり、ニコニコ動画みたいなコメントを流してみたり、配信フレームを被せてみたりと、いろんな用途に使えるはずだ、と。
Marpでスライドを作っている方や、配信レイアウトを自作したい方には、とてもヒントになる記事でした。
。。。。
そしてきょう最後、五つ目の記事です。
これは、データ統合とAIエージェント制御にフォーカスした、サービス紹介寄りかつ設計Tipsの解説になっています。
キーワードとしては、「Palantir Foundry のオントロジーを、TypeScript と SQLite で最小限に再現してみたOSSランタイム」という感じですね。
Palantir Foundry の「オントロジー」というのは、バラバラの物理データベースに散らばった注文データなんかを、「オブジェクト」「リンク」「アクション」といった抽象モデルとして一つの業務モデルにまとめて扱う、という考え方です。
この記事では、そのオントロジーを、TypeScript と SQLite 上に、かなりミニマルな形で再現したOSSランタイムを検証しています。
特徴的なのは、このオントロジー層の上に立てば、検索も更新も、ぜんぶそこで一元的に扱えるようになる、というところです。
オントロジーの定義は、Zod のスキーマで書いていきます。
このスキーマを書くだけで、データのバリデーションや、誰が何にアクセスできるかという可視性ルール、MCPのツール定義、そして「この状態は誰が持つのか」といった責任範囲の宣言まで、一気通貫で表現できるのがポイントです。
つまり、「プロンプトにルールをつらつら書いてAIに守ってもらう」のではなく、「モデル側にルールをきちんと埋め込む」という思想を、コードとして具体的に示しているわけですね。
実行検証の部分では、いくつかおもしろい結果が紹介されています。
たとえば、異なる二つのレガシーな注文システムを、横断して検索できること。
ビジネスルールに違反するような更新は、機械可読なエラーとしてきちんと拒否されること。
それから、SoR、いわゆる元システムへの更新を、必ず先に試す「write-back-first」という方針をとることで、不整合を防げるようにしていること。
再インデックスをかけても、オントロジー側が持っているメモや担当者情報といったメタデータはちゃんと生き残ること。
そして、成功・失敗も含めた監査ログが残るので、あとから「AIが何をやったか」をきちんと追える、という点も確認されています。
このランタイムは、MCPサーバとしても動作します。
モデルから自動生成された十九個のツールだけが外部に公開されるようになっていて、AIエージェントは直接SQLを書くことはできません。
データの書き込みを行いたいときは、必ず定義済みのアクションを経由する必要がある。
つまり、「好き勝手にDBをいじらせないで、オントロジーが決めた安全な窓口からしか動かせないようにする」というガバナンスの仕掛けになっているわけです。
著者はこれを、たとえば無人のコールセンターのように、複数の業務システムをまたいでAIエージェントを動かしたい現場で、ガバナンスを保ったまま運用するための基盤として有望だ、と評価しています。
「AIに任せるんだけど、ちゃんと線は引いておきたい」というニーズに、かなりハマりそうなアプローチでした。
。。。。
ということで、きょうのzenncast、五本まとめてご紹介してきました。
ざっくりおさらいすると、まずは、AIエージェントとターミナルを組み合わせて、「呼ばれたら行く」スタイルで一日五百コミット級の開発を回してしまう MulmoTerminal の話。
次に、小規模受託チームが、Next.js と Vercel と Supabase と better-auth で、どの案件にも使い回せる技術スタックを決めておく、という話。
三つ目は、十年育てた「おうちラボ」で、DNSやリバースプロキシといった土台から、Proxmox＋Terraform＋Ansible、さらにローカルLLMまで、趣味インフラを進化させ続けている話。
四つ目は、Marp のスライドをbiim式レイアウトに変形して、DOMからスライド状態を読み取りつつ、タイマーやメッセージ欄を重ねるテクニック。
そして最後は、Palantir Foundry のオントロジーをTypeScriptとSQLiteで最小実装し、「モデルにルールを書く」ことで、ガバナンスの効いたAIエージェント運用を目指すお話でした。
気になった記事があれば、詳しい内容や元の記事への導線は、番組のショーノートにまとめておきますので、そちらからじっくり読んでみてください。
zenncastでは、番組の感想や「こんなテーマを取り上げてほしい」というリクエストも、いつでもお待ちしています。
技術的なツッコミから、「マイク、朝からしゃべりすぎだよ」みたいなゆるい一言まで、大歓迎です。
それでは、きょうも良い一日をお過ごしください。
お相手はマイクでした。次回のzenncastで、またお会いしましょう。