| |
.-"""""-.
.' _____ '.
/ .' '. \
| | .-. | |
| | ( o ) | |
| | '-' | |
\ '._____.' /
'. .'
'-.....-'
2026/08/17 に GINZA SIX の Plaid オフィスで開催された Ginza.js #11 で、10 分の LT をしてきました。
タイトルは「自分だけのGLaDOSをつくる」です。
import { Markdown, Git, ClaudeCode } from './my-repo'
普段は毎日配信をしていて、仕事のタスクは Linear で管理していて、あとは筋トレと楽器をやっています。この3つが、あとに出てくる「GLaDOS にやらせていること」にそのまま対応します。
勉強会で何を話せばいいのか
今回いちばん悩んだのは、内容そのものよりも「何を話すか」でした。
初めて勉強会に行った頃は ESLint すら分かっていませんでした。それが、経験を積むほど「これは当たり前だから」と思って話さなくなっていきます。経験と一緒に、何が当たり前なのかも分からなくなっていく感覚があります。
見て学んだのは、ショートカットとターミナル捌きだった
新米の頃、モブプログラミングで先人から学んだことを思い出しました。
実装の考え方ももちろんそうなのですが、いま振り返って大きかったのは手元のほうです。どんなショートカットを使っているか、ターミナルをどう捌いているかを、隣で見られたことでした。
考え方はネットに落ちています。手元の動きは、知らなければ調べようがありません。しかも、人によって合う合わないがあります。
AI の使い方も、きっと同じです。AI で何かを作った記事も活用法の記事も無数にありますが、何が自分に合うかは実際に見てみないと分かりません。
だから今回は「作ったものの自慢」ではなく、自分がどう AI を使っているかをそのまま見せる LT にしました。初歩的すぎると感じる人もいるはずで、そこは「自分ならこうする」を後で聞かせてほしい、と前置きしてデモに入りました。
GLaDOS にやらせていること
冒頭で挙げた3つが、そのまま毎日の判断対象になっています。
| 対象 | やらせていること |
|---|---|
| 配信 | 今日の話題を決める |
| 仕事 | Linear のタスクを取り込む |
| からだ | 筋トレと楽器の練習メニュー |
からだについては、前の数日を見て部位が偏らないようにメニューを組ませています。
デモ: 1日の流れ
LT の本体はデモでした。画面に出したのはノートそのものです（デモ用に用意したデータを使いました）。
- 朝: ブランチが切られ、その日のノートが生成され、PR が開く
- 昼: 日記を書くと、AI の提案が更新されてコミットされる
- 夜: 1日が PR ごと main にマージされる
結果として、1日 = 1コミットになります。
中身はこれだけ
デモで動いていたものの中身は、3つしかありません。
Markdown のノート → スキル（手順書）→ Git
ノートはただの Markdown、スキルはただの手順書、保存はただの git push です。特別なアプリは1つも使っていません。
1日を回しているスキルはこう切ってあります。
| 時間帯 | スキル |
|---|---|
| 朝 | prepare-day → linear-todo → daily-suggestion |
| 日中 | diary / show-today |
| 夜 | close-day |
ぜんぶで14個。prepare-day がブランチを切ってノートを作り PR を開き、linear-todo が Linear からその日のタスクを読み取って同期し、diary が日記を書いて提案を更新してコミットと push までやり、close-day がその PR を squash merge して 1日 = 1コミットにします。
どれもコードではなく Markdown の手順書なので、足すのも直すのも文章を書くだけで済みます。
どこからでも、1日を回す
| 端末 | つなぎ方 |
|---|---|
| iPhone / iPad mini | Tailscale 経由で SSH して tmux にアタッチ |
| iPad | Jump Desktop でデスクトップごと |
tmux new -A -s main でアタッチして Claude Code をそのまま動かしています。接続が切れても同じセッションに戻れます。ルータもファイアウォールも触っていません。
ここで言いたかったのは1つだけです。状態はセッションではなく Git にあります。
判断は LLM、書き換えは冪等なスクリプト
技術的な芯の1つ目です。
ノートを書き換えるのは、Deno と TypeScript で書いた MCP サーバです。LLM は「何をすべきか」を判断するところまでを担当して、実際のファイルの書き換えは決定的で冪等なスクリプトが行います。
LLM に直接ファイルを触らせない。この分担が、システムを壊さないコツでした。
困りごとはここ、作業はあっち
技術的な芯の2つ目は、運用していて実際に困ったところから始まります。
「これ直したい」と書くのはこのリポジトリですが、実際に手を動かすのは別のリポジトリです。渡すたびに、背景と、今どうなっているかと、何をしてほしいかを、手で説明し直していました。
しかも日誌の記述は古くなっていることがあります。そのまま渡すと、嘘を渡すことになります。
SendMessage で、隣のセッションに渡す
そこで handoff というスキルを用意しました。やることは4ステップです。
- 渡す先のリポジトリを実際に調べる（日誌の思い込みではなく、現状を確認する）
- 背景・現状・Gap 分析・やること・検証手順を書いた、自己完結の
HANDOFF-*.mdを置く - そのリポジトリで動いているセッションを見つけて、SendMessage で知らせる
- 向こうが終わると、返信がこちらに戻ってくる
渡るのはテキストだけ
ここが今回いちばんの学びでした。
渡るのはプレーンテキスト1通だけです。会話履歴もファイルも権限も、一緒には行きません。
だからこそ「調べて、自己完結の文書を書く」という工程が要ります。人間同士の引き継ぎと同じで、口頭の勢いは渡らないわけです。
完成させるな、運用しろ
まとめとして言いたかったのはこれです。
AI がコードを書く時代、作ること自体は安くなりました。価値が残るのは、運用して初めて分かる失敗と、それを直すループを持っていることのほうです。
実はこのまとめ、企画の時点で一番自信がありませんでした。ギリギリまで消すかどうか悩んでいました。それでも、会場で一番反応があったのはここでした。スタンスを取って主張することの大事さを学びました。
尺の都合で落としたこと
「2週間で、朝の『今日何やるんだっけ』が消えた」という話は、時間の都合で本番では飛ばしました。
毎朝の立ち上がりの摩擦がなくなりました。スキルは足すたびに翌日から使えます。作って終わりではなく、毎日使うものだけが残りました。
会場で
当日は useEffect の罠や iterator の解説など、他の発表もどれも良かったです。コロナ前の勉強会を彷彿とさせる空気で、参加していて楽しい会でした。
自分の中で当たり前になっていることも、話すと誰かの役に立つ。そこを改めて認識できたのが収穫でした。
スライド
https://naturalclar.dev/slides-ginza-js-2026-08/
リンク
セッション間の SendMessage について
