Masteries

技術的なことや仕事に関することを書いていきます.

YAPC::Fukuoka 2025お疲れ様でした!

これはPerl Advent Calendar 2025の25日目の記事です。そういうことになっています。

qiita.com

昨日の記事は「Perl 5.42 から新しく入った警告を試してみる」でした。

shogo82148.github.io


…というわけで、タイトルにもある通りYAPC::Fukuoka 2025お疲れ様でした(まだちょっと残務がありますが…)。

listen.style

概ね、運営側としての感想などは先日「ツナギメエフエム」さんに出させていただいた時に話したんですが…。確か、「薄氷の上で全力でシャトルランしたけど、何故か落ちなかった状態」みたいな喩えをしたと思うんですが、まさにそういう感じでした。

まあ、とにかく反省点しかなかったし、このドタバタに巻き込んでしまったコアスタッフやボランティアスタッフの皆様にはお詫びのしようもない状態で、一方でなんとか最後まで走り切れたのは、コアスタッフやボランティアスタッフの皆様が当日臨機応変に動いてくださったおかげです。今回、YAPC::Japanのコアスタッフ経験者を招聘する手を打ったのですが、これがなかったら多分何かが大爆発していたのではないか。それくらいギリギリの綱渡り状態でした。

そのへんの考察というか何というか、忘れないために戒めの気持ちでブログを書いておこうと思いました。

原因

今回、こんなドタバタになってしまったのはとにかく最後に「帳尻をあわせられなかった」、そしてそもそも帳尻をあわせる必要が生じた原因は「タスクの集中が発生した」からで、それは「コア側(papix)に覚悟がなかった」、のかなと思っています。

帳尻をあわせられなかった

前提として、(YAPC::Japan以外のほとんどのカンファレンスもそうだと思いますが…)運営の中枢を担うスタッフ(YAPC::Japanでは「コアスタッフ」と呼んでいます)に専業のスタッフがおらず、みな本業がある中で余暇を使ってカンファレンスの準備をしています(そして交通費・宿泊費以外は完全に手弁当です)。

そうなると、どうしても開催直前に帳尻をあわせる必要が出てくるのですが、今回のYAPC::Fukuoka 2025では参加人数の増加、2日開催といったイベント側の事情も変わりましたし、自分自身も周辺の状況の変化だったり体力の低下(加齢!)だったりがあって、結構詰めきれなかった部分が多数あり、そこが当日時限爆弾のように爆発した(=スタッフに臨機応変に対応いただくことになった)と思います。

YAPC::Kyoto 2023のときは、もうちょっとマシに帳尻をあわせられた…と思うのですが(もちろん万全ではなかったが、今回ほどひどくはなかった…はず!)、とにかく今回のように「最後に帳尻をあわせるやり方」は状況によって捌けない場合があり、持続可能性がない!ということを強く思いました。というかまあ、このへんは前々からわかっていたつもりだったけど、今回自分が圧倒的にやらかしてみて、初めて心の底から痛感したというか…。

「一切帳尻をあわせる必要がない」ように準備をするのはやはり難しいですが、とはいえなるべく減らす手は打てるはず。特に、次のYAPC::Tokyo 2026はYAPC::Japanとしては過去最大級になるので、当然準備期間にやること(タスク)も増えます。これまでのやり方を踏襲すると、恐らくYAPC::Fukuoka 2025以上に帳尻をあわせる必要が生じて、確実に大変なことになってしまいます。

タスクの集中が発生した

ではなぜ毎回毎回帳尻をあわせる必要があるのか…?を考えると、その理由は「タスクの集中が発生した」から。多分これはYAPC::Japanになってから(少なくともコロナ後にリブートしてから)はずっと問題になっているはず。運営側としては問題として認識しているものの、まだ有効な手を打てていない、という状況です。

ここ最近のYAPC::Japanは、毎回会場が変わっています。これによって運営の中枢を担うコアスタッフも、その開催地にお住まいの方を中心にお声がけしています。結果として、毎回新しい施策をやる度に(一部のコアメンバー=JPAの理事を除いて)新たにチームを組成しているような状態になっています。

同じカンファレンスであっても、会場が変われば準備する内容もその前提も大きく変わります(特に、僕は「同じようなカンファレンスを繰り返す」ことに良い印象を持っていないので、毎回新しいことをやりたがるのも良くない)。そもそも参加者として見るカンファレンスとスタッフとして見るカンファレンスは別物で、過去にYAPC::Japanに参加したことがあるからといって、すぐさまコアスタッフとして100%理解して動けるという方はいないと思います(かつて自分がYAPC::Japanのコアスタッフになった時もそうでした。2〜3回継続してコアスタッフとして動いて、なんとかやっていけるかな…?という程度になった記憶があります)。

なので、「全コアスタッフがタスクを奪える(取り組める)ように、タスクを細かく設計・分解する」必要があるのですが、この作業はどうしても複数回YAPC::Japanの運営に携わったことのある一部のコアメンバーしか担う事ができず、そのメンバーに負担が集中してしまいます。 これについては、「実行委員」というJPAの理事ではないがYAPC::Japanの運営に中長期的に関わる(関わっていただく)役職をJPAに設けて対応しようとしていますが、その成果が出るまではもうちょっと時間が必要そうです。

コア側(papix)に覚悟がなかった

ただ、そもそも「タスクを細かく設計・分割できた」としても、それをコアスタッフにちゃんと分配できたか?というとそれも怪しく…。というのも、前述の通りYAPC::Japanのコアスタッフは基本的に手弁当で、業務や私事の間に準備に取り組んでいただく必要があり、そう考えるとあまりタスクを渡したくない、という気持ちは正直あります(依頼することに精神的負担を感じて、遠慮してしまう)。

人を増やして人海戦術で乗り切る、という作戦もありますが、これはこれで人が増えれば増えるほどコミュニケーションコストが増加して、別の精神的負担(調整等)が発生しそうです。

これが仕事であれば、自分も相手も会社からお金をもらっているので声をかけやすいのですが、YAPC::Japanのように善意に基づいた手弁当(=報酬なし)だと、どうしてもそのへんのやり取りが難しい。結果として、ある程度は自分でボールを持って…となると、前述の「タスクを細かく設計・分解する」もできず、更にタスクがコアメンバーに集中して…。という悪循環になっている気がします。

これはもう、自分に覚悟がなかったのが原因で、タスクを依頼することによって生じる精神的負担としっかり向き合う必要がありました。例えば、自分が「タスクを細かく設計・分解する」に集中すると、コアスタッフからすると「papixはタスク割り振ってくるけど、自分は何もしないじゃん」という風に見えるかもしれません(事実ではある)。これまでのように「そう思われるのは嫌だな」、で逃げるのではなく、「それが自分の仕事だから!」と、覚悟を持ってやり切る必要があると思います。

あとは、そもそも「依頼できる」関係性をちゃんと構築する、というところにもう少し時間とコストを割いても良かったと思います。思えば、前回のYAPC::Fukuoka 2017のときは毎月(!?)福岡に行って定例ミーティングをしていたのですが、コロナ禍以降は「意外と何とかなるな」でリモートで定例ミーティングを行うようになっています。従来のように毎月現地に行くのは難しいとしても、もう少し高頻度にコアスタッフが集まれる機会を作ってもいいのかな、と思っています(YAPC::Fukuoka 2025では何度か会場下見という体で福岡に行きましたが、東京と福岡でコアスタッフが分散していたこともあって、事前に全員集まって交流する、という場を作ることはできませんでした。最初に or 忙しさが増してくる中盤に、一度みんなで集まるという機会が作れれば少し状況は変わっていたかもしれません)。

今後の展望

なんかこういう話をしていると、「papix、責任取ってJPA辞めるのか?もうYAPC::Japanやらないのか?」という雰囲気もありますが、今のところそのつもりは一切ないです。少なくとも、こういった問題を解決して、持続可能性を高めるまでは退けないと思っています。個人的には一生YAPC::Japanしていきたいものの、一方で業務事情、家庭事情、体調事情等で、JPAやYAPC::Japanに関われなくなる時が来る可能性は0ではないので、そうなってもいいように準備しておくのは必須です。その覚悟(?)を表すべく、このブログをしたためた次第です。

幸い、次のYAPC::Tokyo 2026では id:karupanerura 御大がこれらの問題の解決に向けて動いてくださってるので、これまでのように、これからも(ちょっとずつかもしれませんが…)状況は改善していくと思います(できなかったら多分あと5年くらいでYAPC::Japanは継続不能になると思う。現時点でトラックナンバー1だし…)。自分も、JPAの一員として、そしてYAPC::Japanのメンバーとして、その力になりたいと思っています。


良かったこと

…なんかネガティブな話題で終わるのも悲しいので、個人的に良かったなということを書いておきます。

  • 大きな問題なく終わることができた
    • もちろん前述の通り運営準備がハチャメチャで、細かい問題は大量に発生しましたが…。コアスタッフ・ボランティアスタッフの尽力で概ね対応でき、またイベントを中止するような大きな問題も発生しませんでした。参加者の皆様のご協力ありがとうございました。
  • 会場の福岡工業大学が大変良かった
    • あの規模の会場をあの価格で借りれるのはすごい!
    • 福岡工業大学の管財課など、関係各所の皆様の対応が神だった。正直、下手なセミナー会場よりも迅速・丁寧に対応いただけて、会場側との折衝について不安になるシーンがなかったです。福岡でカンファレンスやるなら福工大は選択肢に入れる価値あると思います。
  • 懇親会にビアキチ呼べた、結果としてpapix meltdownしなかった
    • ほぼ個人の趣味でビアキチを呼べたのも良かった。福岡でやるなら… ビアキチを呼びてえよな…。というほぼ自分のワガママで進めたけど、ビール飲める方は満足してくださったようでよかった。
    • ビアキチのビール、好評ですぐなくなって、「このあとに瓶ビール飲むのもな…」と思ってアルコールを控えた結果、過去2回発生していたpapix meltdown(スタッフ懇親会での寝落ち)が発生しなかったのもよかった。
  • エンディングムービーが良かった
    • 「なんか… エンディングムービーがあるといいよネ…?」という最悪な要件定義からあのエンディングムービーが出てきてびっくりした。正直初見で泣いた。
  • 学生旅費支援、U29支援など各種施策を継続できた
    • これについては自分がYAPC::Japanに関わっている間はなるべく継続します。
  • なんだかんだ楽しかった!
    • とにかく今回は大変だったし、反省点しかないけど、懇親会とかブログとかで「楽しかった」って言ってもらえると… なんか楽しくなるんだよね…。
    • これがあるからカンファレンス運営はやめらんねえ!(個人の感想です)

…というわけで、来年の11月に東京ビックサイトでお会いしましょう!

2025年、AIに関する技術をどのようにプロダクト開発に取り込んできたかをまとめてみた

この記事は、「toggle Advent Calendar 2025」の7日目の記事…のはずでした。投稿日は見ないでください。

qiita.com

6日目の記事は、「2時間の自律動作 - Opus 4.5で実践するエージェント開発」でした。

zenn.dev


2025年が終わりに近づいてきました。この1年を振り返ってみると、自分にとっては「AIに関する技術が、急激にプロダクト開発の中に定着した(当たり前になった)」1年になったな〜、と思っています。 そしてその内容(自分の中のベストプラクティス)も、AIに関する技術が急速に進化していく中で、本当に毎月(下手したら週レベル)でどんどん変わっていったように思います。

この1年を振り返りつつ、あとから「2025年はこんな感じだったんだな…」というのを振り返られるように(案外、忘れてしまうので)、2025年自分がプロダクト開発においてどのようにAI技術(AIツール)を取り込んできたか、という観点で振り返ってまとめてみようと思います。

Cursor

まず、4〜5月頃からCursorを導入し始めました。この頃は、比較的まだ自分の手でコードを書いていて、その補完(これまでのGitHub Copilot等の補完よりも精度が高く、tabを押して補完するだけでそれっぽいコードが出来上がっていって、「おお〜」と思った記憶があります)と、あとはコードの分析などに使っていました。

会社でCursorの導入が始まった頃、「1年払いにしたほうが安いので、そうしましょうか?」という声に対し、CTOの id:myfinder が「このあたり、進化が激しいから月払いにして様子見ましょう」といったことを仰っていたのを今でも覚えています。実際、後述しますが夏頃にはCursorをほぼ使わなくなった(Claude Code/Codexにシフトした)ので、この見立ては完全に正しかったと思います。

当時のCursorは、たまに「謎な(?)」回答をすることがあったので、そういう時にイラッとしないよう、口調をずんだもんにしたりして遊んだりしていました。意外と効いたと思っていて、「まあ、ずんだもんだしな…。」という気持ちで向き合うことができたような気がします。

papix.hatenablog.com

v0

4月から部署異動があり、新しく社内向けのプロダクトをガンガン作っていくことになりました。 そこで利用を開始したのがv0です。実際にブラウザ上でプロダクトが動いてる様子を見つつ、プロンプトを投げて開発することができて、特にプロトタイピングを作るには本当に有用でした。そのままVercelに展開できるのも魅力的。

ただ、ある程度コード(プロダクト)のサイズが大きくなると、生成に時間がかかったり、質が下がってくる印象があって、最初から最後までずっとv0で開発するのは難しそう、というのが当時の所感でした。そもそも、プロトタイプの開発であれば、今なら最初からClaude CodeやCodexで作り始めても十分モノになりそうです。 一方で、非エンジニア(プログラミングに不慣れな人)が、とりあえずさっくり動くモノを作ったり、プロトタイピングをするという観点では今でも有効に使えると思います。

この頃の考察が以下の記事でした。

papix.hatenablog.com

Claude Code

7月頃からClaude Codeを使い始めました。ここからAIツールに対する向き合い方が大きく変わって、「AIツールを、コードを書く補助に使う」から、「AIツールでコードを書く」にシフトしました。というのも、その頃開発していた(5月頃から開発を進めていた)プロダクトが、

  • 立ち上がったばかりで、小規模
  • 自分1人で開発している
  • 社内サービスなので、障害が発生しても影響範囲が狭い(社内に閉じる)

という状況だったので、「どこまでAIツールにコードを書かせられるのだろう?」と全実装をClaude Codeに行わせてみたところ、ほぼほぼ問題なく仕事を進めることができたので、「じゃあ、このままどこまで行けるか試してみよう!」となったのでした。結果としては今の今まで、ほとんどすべての実装をClaude Code(と、後述するCodex)というAIツールに任せることができています。

Claude CodeやCodexなどAIツールを使って実装を進めた場合、(定量的な評価ではなく定性的な評価ですが)自分で実装したときの60%〜70%くらいの成果物を一発で出力してくれて、人間がレビューや動作確認をしてフィードバックを与えていけば、普通に80%〜90%、更には100%も十分に目指す事ができるんじゃないか、という印象があります。 そうなってくると、もはや自分の手でコードを書くのは時間がもったいない(どう頑張ってもAIツールより早くコードを書くことはできない!)、ということで、

  • 「何を」作るかをしっかり考える
  • (後から変更するのが大変な)データ構造を決定する
  • 作ったものを評価をする(実装、挙動)

人間はこういうところに集中して、実装はAIツールに任せる、という形に落ち着きました。

そうなると、自分の手でコードを書けなくなったり、読めなくなるんじゃないか?と心配になると思います。自分も最初はちょっと心配だったのですが、「将棋の渡辺くん」という漫画で将棋の渡辺先生が「数カ月、将棋の勉強をしなくても将棋を打てた」というエピソードを紹介されていて、であれば自分もそれくらいコード書かなくても大丈夫なのでは…?と思い、勇気を出して(怠惰に流れて、とも言う)やっていっています。

先日、チームに新卒のエンジニアが入って開発が2人体制になり、久々に(人間の書いたコードの)コードレビューをすることになったのですが、「意外とというか、普通に読めるな」と感じました。コードを読めるのであれば、(CursorなどAIツールのサポートを得ることができれば)コードを書くこともできるだろう、と思っています。このへんは、今後今取り組んでいるプロダクトが全てAIツールに任せられなくなったときに本当の結果がわかると思います。

この頃に書いた記事はこのあたりでしょうか。

papix.hatenablog.com

papix.hatenablog.com

Codex

prtimes.jp

10月頃、現所属会社とOpenAIの業務連携、というプレスリリースが出て、これによりClaude CodeからCodexを活用する方向にシフトしました。Claude Codeはガンガン使っていると簡単にレートリミットに達するのですが、(弊社の場合、業務連携の影響か)Codexはその心配がほとんどないので、とにかくCodexでガンガンタスクを回すようになりました。

ただ、個人的には

  • Claude Codeは設計(実装)が得意
  • Codexはレビュー(評価)が得意

という印象があり、そのため、

  • Claude Codeと対話しつつ設計、実装
  • その結果をCodexにレビューさせる
  • フィードバックをClaude Codeに渡して修正

…みたいな感じで作業を進めていたように思います。

また、この頃から「とにかくエラーが出たら、Claude CodeなりCodexに食わせる」ようになりました。これまではログをGoogleに投げて調査をしていましたが、Claude CodeやCodexに投げればインターネットの知識をもとに推察して、更に解決案の提案から修正までやってくれるので、「もうこれでいいな…」となりました。そう思ったきっかけが以下のエントリです。

papix.hatenablog.com

Vibe Kanban

10月からVibe Kanbanを使い始めました。これは6日目の記事を書いたbokiさんが教えてくれたツールです。詳しくは id:azukiazusa さんの記事がオススメです。

azukiazusa.dev

これまで、tmuxで複数タブを開いてClaude Code/Codexで開発をしていたのですが、並列数が増えると「このタブは何の作業をしていたんだっけ…?」がわからなくなって、脳の負荷が高まるという状況(?)が発生していました。せっかく(レートリミットに達しない限りは)文句を言わずにClaude CodeやCodexが仕事をしてくれるのに、人間(自分)がボトルネックになっていました。具体的には3並列を超えてくるとだいぶしんどくなってきた記憶があります。 Vibe Kanbanを使うことで、現在Claude CodeやCodexなどAIツールで行っているタスクとその状況を簡単に可視化できるようになり、ほぼ無限にスケール(タスクの同時進行)できるようになりました。

「こういうことがしたい」、「こういうのがあればいいな」と思ったら、とりあえずVibe Kanbanに登録しておく、或いはVibe Kanbanで実装させておいて、「やっぱりいいか…」となったらサクッと捨てられるというのがいいですね。

今後の課題

Vibe Kanbanによって同時実行ができるようになった結果、現在のボトルネック(?)は節操もなくガンガン使っているとすぐに到達してしまうClaude Codeのレートリミットになっていて、これをなんとかする方法を考えています。

直近は、Claude Codeのplanモードがかなり強力(これまでは、似たような処理を行う/tasksというコマンドを実装して使っていましたが、不要になりました)なので、これを使って

  • 「こういうのを実装したい」を与えてClaude Codeにプランを建てさせる
  • このプランをCodexに渡して実装
  • Codexにコードレビューと修正をさせる
  • (最後に自分がレビューして、マージ)

というフローにしつつあります。なるべくCodexを活用することで、Claude CodeのRate Limitに達しないように工夫しています。

今後の課題や展望など

prtimes.jp

何故か(何故か?)、DGX Sparkが配られたので、これをもっと活用していきたいですね。 DGX SparkにClaude Code/Codexを導入してVibe Kanbanを立ち上げておけば、いつでもどこでも(業務用のノートパソコンが壊れても)DGX Sparkさえ生きて動いていれば仕事ができる、という環境を作りたいですね。

また、Claude CodeとCodexについて、現状連携についてMCPを使っておらず、手動で(=プロンプトなどを人力でコピペして)連携していますが、これもMCPを使ってシームレスに連携できないか?というところも模索していきたいです。

あとは、現在取り組んでいるプロダクトが社内向けなので、割とガンガンAIツールの利用に寄せることができていますが、これが社外向けに展開されるようになった場合、テストやQA、品質保証についてしっかり考えないと、障害が発生したりして大変なことになりそうです。これは今後の課題になりそうですね。

最後に、「どうすれば実装をAIツールに寄せ続けられるか(人間が実装しないで済むか)」というところも考えていきたいです。ここが明らかになれば、「ここからは人間が実装していきましょう」という判断を迷わなくて済みますし、「こうすれば、実装をAIツールに寄せ続けられるぞ」と工夫することもできそうだからです。

最後に

もはや、プロダクト開発において「AIに関する技術を一切使わない」という選択肢はないな…。という時代になってきました。当面は、どこで、どれくらいAIに関する技術を使うか、というところをしっかり考えていく必要がありそうです。


8日目の記事は「DXF/DWG解析の時に使えるezdxfを使った便利技」です。

qiita.com

宣伝

1月にDGX Sparkに焦点をあてた「DGX Spark Meetup」をやります!ぜひ遊びに来てください。

toggle.connpass.com

忘備録: Macで特定のディスプレイを繋いだときに映らない問題への対応

Macで、ある特定のディスプレイを繋いだとき「だけ」映らない、という問題が発生していました。そのとき、ふと id:xtetsuji さんが「とりあえずMacのログをClaude Codeとかに食わせたら解決できるんじゃないですか?」と仰ったので試してみたところ、本当に解決できたので忘備録です。

前提

  • MacBook Air
  • Apple M3
  • Sequoia 15.5

対処方法

ディスプレイを繋いだり外したりして、そのときのコンソールのログをごっそりClaude Codeに食わせたところ、以下のログが怪しいと指摘してくれました。

com.apple.AmbientDisplayAgent    [ERROR] - Unable to create and lookup port "com.apple.CoreDisplay.master" => 1102

で、Claude Codeにwebsearchで調べてもらうと、以下のコマンドで修正できそう、との回答が。

# ディスプレイ設定ファイルのバックアップと削除
cd /Library/Preferences
sudo cp com.apple.windowserver.displays.plist ~/Desktop
sudo rm com.apple.windowserver.displays.plist

# NVRAMクリアと再起動
nvram -c
sudo shutdown -r now

試すと本当に解決しました。しかしまあ、こういうトラブルシューティングは本当にAIは得意ですね…。

ソース

ちなみにClaude Codeに「ソースは?」と聞いたところ、次のブログを挙げてくれました:

note.com

difitとpecoを組み合わせたら捗りそう

先月からClaude Codeを使い始めたのですが、そうなるとClaude Codeが実装したものをレビューする、という機会が増えてきました。最初はtigコマンドで見ていたのですが、やっぱりGitHubのdiffっぽい(?)インターフェイスでレビューしたい、と思っていたところ、difit(旧reviewit)が登場したので、最近はもっぱらこれを使っています。

github.com

直近のcommitの差分を見るのであればnpx difitでいいんですが、たま〜に少し前のcommitの差分を見たい、となるときがあって、そのときにcommit hashを調べたり、HEAD^^みたいに指定するのはちょっと面倒だな〜、と思う時がありました。

さっきふと、「あ、pecoを使えばいいじゃん!」と閃いたので、次のようなコマンドを用意してみました。

git log --oneline --decorate | peco --prompt 'COMMIT >' | head -n 1 | awk '{print $1}' | xargs npx difit

git log --online --decorateの内容をpecoで絞って、ここからcommit hashを取得して、xargsdifitに渡す、という感じです。これで、difitで見たいcommitの選択を、pecoで実現することができました(pifitpecodifitpifit)という名前で実行できるようにしています)。

AIコーディングエージェントにログを(強引に)見せる

最近はClaude Codeの導入というかトライアルを進めているのですが、エラーが発生したときにその内容を共有するところで少し面倒を感じつつあります。

具体的には、AIコーディングエージェントが直接ログ(npm run devで開発中のプロダクトを動かしたときのログ)を見れないので、丁寧にコピーして貼り付けて「このエラーを修正して」と作業する必要がある… という点です。

mcp-daemonize

mackee.hatenablog.com

github.com

解決策の1つとして、 まこぴーさん( id:mackee_w )の「mcp-daemonize」を試しました。これを使えば、コーディングエージェントに開発サーバを起動させて、ログも見れるようになって問題は解決したのですが、今度は逆に人間(自分)がログを簡単に見る術がない、という点が気になりました。

ブログを見た感じ、まこぴーさんの使い方だと、でかいタスクを事前に丁寧に設計して、あとは自動運転… という感じで使われているようです。こういう使い方であれば、自分のように人間がログを見る必要はないように思います。一方で、自分はコーディングエージェントに対して細かいタスクをちまちま投げる時もあって、そういう場合は都度都度ログを確認しつつ動かしたいので、人間もログを簡単に見れるといいな…と思いました。

こういうときはPull Requestを送ろう、と思ったのですが、そもそも本当に(少なくとも自分にとっては)人間がログを簡単に見れると便利になるの?ということを予め検証しておきましょう。折角実装してPull Requestを送ったのに、いざ動かしてみたら「なんか思っていたのと違う…」となったら大変ですからね。

強引に試す: ログを吐いてAIコーディングエージェントに読み込ませる

unbuffer npm run dev 2>&1 | tee ./.tmp/log

...とにかく試してみるのが目的なので、強引に行きました。

  • tee コマンドでログをコンソールに表示しつつファイルにも書き出す
    • unbuffer を使うことで色付き表示を維持させています
  • そして、AIコーディングエージェント(今回はClaude Code)には ./.tmp/log を読み込ませる

これで動かしてみると、

> ./.tmp/log にアプリケーションのログがあります。これを確認して発生しているエラーを修正してください。

(中略)

⏺ Read(.tmp/log)
  ⎿  Read 23 lines (ctrl+r to expand)

⏺ エラーが見つかりました。...(以下エラーの解説)...

…という感じで、ターミナル上にnpm run devのログを残して人間が簡単にログを確認できる状況を維持しつつ、コーディングエージェントにもログを読み込ませることができました(今回はNext.jsプロダクトでの事例だったのでnpm run devですが、他のコマンドでももちろん使えると思います)。

暫くこれで試してみて、やっぱり人間もログ見れたほうが良い!と思ったら、「mcp-daemonize」にPull Request送れないか考えてみようと思います。

参考文献

なお、 unbuffer コマンドについては以下のブログを参考にしました:

blog.ayakumo.net