結局一年もすれば「そんな記述要らなかったんだ」となると思うので、今そっち方向でメンテナンスに時間をかけるのは得策ではないのでは？と思い始めた。それよりは最近取り組んでいる、スクリプトでのフロー管理や、それを簡単に呼び出す仕組みの方が長く使えるものとしていけそう。LLMの得意なことは入力に反応してアクションすることであって、フローを頭にイメージして行動することではないからかと感じている（これは今後もそうでは？と思うのだ）。
そんなわけで、非同期のプロセス管理の仕組みを用意して試している。これはAIが入力待ちスクリプトを上手に扱えないことを解消するための道具で、次の入力を非同期的に待てる。これによってフロー管理などは入力待ちスクリプトを（AI用とは考えずに普通に）書くだけで実現できる。ユーザーサイドは新しいことを覚えなくても良い仕組み。
オーケストレーションをするために新しい文法を覚えない形をできるだけ模索したい。
最近実装した機能でタイマー機能がある。というのは、AIエージェントは非同期なタイマー機能は持っていないようなので、何かを待たなければいけない時に難儀していたようだからだ。そこで AgentConsoleに、提示タイマーを仕掛けられるようにした。
たとえばCIのグリーン待ちをさせている時に、勝手に仕掛けて待ってくれる。
⏺ PR https://github.com/ms2sato/agent-console/pull/448
を作成しました。CI完了後にマージします。
⏺ agent-console - create_timer (MCP)(sessionId: "b83707dc-0e79-408a-9892-c48d1cd3a45f",
workerId: "43adf357-c6a8-45d6-89cd-77ed6278bbc5",
intervalSeconds: 180, action: "Check CI on PR #448.
Merge if green, then ExitWorktree.")
⏺ CI待ちです。
✻ Cogitated for 49s
❯
[internal:timer] timestamp=2026-04-01T22:33:02.558Z
timerId=a17b441b-e147-4c0b-b89a-dcc57c75a3a1 action="Check CI on PR #448. Merge if
green, then ExitWorktree." fireCount=1 intent=inform
⏺ Bash(gh pr view 448 --json statusCheckRollup --jq '.statusCheckRollup[] | "\(.name):
\(.status) \(.conclusion // "")"' 2>/dev/null)
⎿ test: COMPLETED SUCCESS
null: null
⏺ agent-console - delete_timer (MCP)(timerId: "a17b441b-e147-4c0b-b89a-dcc57c75a3a1")
⏺ Bash(gh pr merge 448 --merge 2>/dev/null && echo "MERGED")
⎿ MERGED
この状態で私から割り込みがかかったら即時処理してくれる。また、定時なので、何回もタイマーはコールされる。定期的な見守り系はこれで対応可能。CTO エージェントが、担当者に作業を振った後、15分おきタイマーを仕掛けて定時チェックしてくれる（報告せずにidleになっていたら状況確認したり）。
AIの活用が広がった時、インターネット上でかざられた文章のほとんどがAI由来になってゆくのだろうか。
例えば商品の発見がAI起点になったとして、発見されるためのWebサイトの収集起点はSEOの結果だったりすると、ここはまだ疎かにできない。
発見された商品のファーストビューはやはりWebページの１つになり、それは人間向けに提供されているはず。
一方、人間向けに魅力的な文章が出力されたとして、その文章がAI由来なのはあり得る。通常ある程度の規範のある会社なら言葉の選び方や品質は適切にチェックされたものであり「確定」の判断があるはず。ここは人間の責任である。
AIに提案させて吟味した上で確定し、世に出て行きそう。
リテラシーの格差も気になる。自分でAI編集者を立てられるような知識のある人は良いとして、そういうことが苦手な人に、どのようにプラスを享受させるか。できれば自然に。
この辺りの人だと、オールインワンの方がいいんだろうな。ネタが提案されるから選ぶと仮文章が作られて、意見伝えると調整されるような。文章の質、世間への配慮はチェック機構があって評価されており、あとは確定するだけで世に出る、もしくは次の担当にエスカレーションされる？
オチはない
弊社のSlackには reports というチャンネルがあるのですが、ここはいわゆる週報を書く場所です。現在では毎週月曜日に皆がこのチャンネルに週報を投稿しています。KPTという形式はもうおなじみになっていると思いますが、弊社の週報もKPT形式で基本的に書いてもらっています。
たった一日で「振り返り」というのは結構しんどいと思うんです。KPTの良いところは「振り返ることで差分がわかる」事なので、適切な差分がわかるだけの時間は必要です。ただ、月報にすると「もう月初のことなんて忘れた」となってしまうことが多いはずです。
さらにマネージャ目線では少しずつ軌道修正ができるような時間幅が良いのです（「先週のあれ、どうなった？」くらいの感覚が持てるのが良い）。なので「週」くらいが長過ぎもせず、短過ぎもしないと思います。
ほぼノージャンルです。もちろん業務のことが全くないのは困りますが、生活習慣の話（これも広義には仕事をうまくやるために必要な事だと思います）や、「個人開発やってるよ」的な軸からの気づきや内容でもOKです。
なんとなくですが、メンバーがそれぞれ少しずつ良くしたいことや、困っていることがここに現れる気がします。それが改善するなら結果的に仕事もうまくやっていけるのではないでしょうか。なので「業務以外の話題は完全にNG」などとする気はあまりありません。
とかく日報・週報はただの記録だったり感想だったりと意味のないものになってしまいがちです。書く側も読む側も意味を感じられないならやめた方が良いです。時間の無駄ですよね。
そんな中でKPTは仮に1人で利用すると考えた時でも、以下のようなところは良いと思います。よく言われていることでしょうけれども書いときます。
メンバーが行っているKPTに私はそれぞれコメントします。ここでやるのは
これくらいですかね。大抵の私の接し方がそうなんですが、私の思い通りに行動してもらうための発言やアクションはあまりしない気がします。「提案はしてみるけれども、受容されないならそれもまぁ仕方ないね」くらいに考えている節があります。別に良いんですよね。最終的にその人の方法で改善できているなら。
週報トリガーで呼びつけるとかしないです。緊急度が高いことなら各プロジェクトのチャンネルで相談くれるはずなので（そもそもこの状態にチームがなっていないならその方が問題ですよね？）、週報に書かれることは「即問題にはならない何か」、「長期的に立ち向かった方が良い課題」、「個人的なこと」なんですよ。それくらいのことで呼びつけられたら萎えますよね。
なので、フワッと覚えといて、何かコミュニケーションのついでに「そう言えばKPTに書いてたけどさ〜」的な会話をする感じです。私は定例MTGが嫌いなので、定例1on1などやったりしません。そうすると何かの業務のついでに行われます。多いのは技術の問題を一緒に解決した直後とか、デプロイを一緒に待っている時間とかですかね。相手の方からその感じで話してくれることもあるので、そうしたら乗っていくだけです。
そうやって話を聞く機会ができてくると、折を見て一緒に掘り下げていくような雰囲気になります。
大体皆が抱えている問題は、自身のものの考え方や、特定の感情を持ってしまう性質に落ちてきそうです。例えばですが
などなど。なんとなくこういう場面で「相手の心に届く一言」が伝えられるかはとても大事なようです。それは比喩のようなものかもしれないですし、方法の話かもしれないし、哲学的な話かもしれないのですが。たとえ届く言葉が伝えられなかったとしても、一緒にその人の芯の課題解決を目指し、扉を一つ開く手助けができるのは信頼も獲得する気がします。
先にも書きましたが、この時「会社や私に都合の良い振る舞いをして欲しい」という目線ではなく「その人の枷が外れてパフォーマンスが上がるのは相手にとって良いことだ*1」という観点での接し方が大切ではないかと考えます。
この辺りの会話からその人の取り組むべき心理が明瞭化されるのは良い傾向と思っています。物事が明文化、明瞭化が進むと解決がしやすくなるらしいです。
続けていたら面白い現象が起こったので紹介しておくと、何年か前の自分のKPTを見返すと結構なショックを受けることがあるそうです。「あの頃、こんなくだらないことを自分の課題にしてたのかorz...」的な心理になるそうで、それはそれは破壊力が高いようです。ただ、そう思えたということはその人は課題を克服したわけですから、成長の証なんですよね。喜ばしいことだと思います。
*1:私の場合は彼らの給与も決めているので、この観点でも彼らの待遇は上がったりします。個人のパフォーマンスが上がれば結果的に会社には都合が良いのですから。
スキルに多数の列挙を書くと読み飛ばされるので、特定のスクリプトを起動することだけを書いておき、スクリプトがウィザード的に振る舞うことで全部の項目を意識させられそうだ。
この時インプット待ちが発生すると作業をストップさせてしまうので、スクリプトを起動し、質問に答えると、同じスクリプトに引数指定して次の質問に答えさせる指示が返るようにした。
この手法は応用が効きやすそうだ。
AIの擬似スプリントの振り返りで、スキルに不要な記述が多い疑惑があったのでバッサリカットしてみたら、動作がキビキビして失敗が減ったので、メモっておく
これまで review-loop という、プロフェッショナルレビュアーがコードレビューする仕組みを各PRごとに実行していたが、トークン消費が大変激しく辛い思いをしていた。
ただ、最近の成果からこれを外して夜中に毎日一回定期実行でもいいのでは？という印象を得た。
費用対効果を考えると、すでに十分な仕組みが整ったと思われる。必要なのはシステムの文脈を理解したチェックであって、通り一遍のチェックをぶん回すことではなかったと理解した。
というわけで今主担当で取り組んでいるシステムについてはreview-loopは一旦封印する。
