ぱいぱいにっき

Pythonが好きすぎるけれど、今からPerlを好きになりますにっき

生成AIコーディングを行うときのエンジニアの役割はレビューとデバッグとデプロイになるのだろうか

最近はClaude Codeとcc-sddを使って仕様書駆動開発(SDD)をしています。SDDをやる前は出てくる実装はガチャ感が強く、まずは荒削りで出した上で、修正をしてもらったり、自分で修正をするということをやっていたのですが、SDDではその修正の過程がそこまで大掛かりになったりしないように思えます。あと実装自体を捨てるみたいなことはあまりなくなりました。

今はどういうふうにやっているかというと

  • cc-sddでrequirements, design, tasksを起こす
  • requirements, design, tasksそれぞれをレビューしてフィードバックを返しながらブラッシュアップをする
  • cc-sddで実装を開始する。途中気付いたTaskの修正などはしたりするものの、だいたい最後まで走らせる
  • 動作確認を私が行う。その過程でうまく動かなくなかったことなどをフィードバックしたり、大掛かりになりそうだなと思ったら別の修正用のspecを起こす
    • ここで動作確認の原因究明まで私がやる場合がある。問題の当たりの付け方がそこまでうまくない, 直し方の筋が悪い, 最初に思いついた仮説に固執する, ログを出して問題解決だと言い張ったりする, 実装して気付いたアーキテクチャ上の問題を指摘できないなど
  • 実際にサーバー上などにデプロイする。デプロイした後の動作確認で見つけた不具合等をフィードバックしたり修正用specを起こす

まあ概ねこれでいいなと思ってて、細部のレビューとかをもう少し楽にしたいなとは思っていますが、だいたいこんなもんでしょうと。ただ、

一方でこの実装フローでいう私の役割というのは、

  • PRDを作成し、壁打ちしたりレビューしてフィードバックする
  • 実装デザインについてレビューしてフィードバックする
  • タスク分解についてレビューしてフィードバックする
  • 出来上がったものの動作確認を行なってデバッグをする, フィードバックをする
  • 出来上がったものをデプロイする

そんな感じで、レビューとフィードバックとデバッグとデプロイみたいな領域になっているなあと。で、この辺りは人間が出てくる場面が少なくなっていく(レビューの頻度は下がる, デバッグの精度は上がるなど)ことはじわじわあるかもしれないが、おそらくこれらの過程は「これでいく!」と決める部分を内包している行為だと思われる。どこまで行っても意思決定をする人はなくなりそうもない。

人によっては(今でも)ガチャのように出てきたものを信じて言われるがままデプロイして破滅!、AIに直させるみたいなことをしている人もいるだろう。私も一部の領域はそうなっていると感じる。あーこりゃ本腰入れて読まないと解決せんなって時は読むんですけれど。あと一発でうまくいかないと困る部分(データとかね)はちゃんと読む。「これでいく!」or「ちゃんと見るか」みたいな判断をする部分にエンジニアリングの知識が絡んでいる。私はこのへんの勘所を実際に自分が手を動かすことで身につけてきたと思っているんですが、本当にこれからどうなるんですかねえ。実装ガチャの試行回数と破滅からのリカバリーでたまたまうまくいったかが実装の成功を左右するようになるんでしょうか...

YAPC::Fukuoka 2025 非公式リジェクトコンを開催しました&発表した #yapcjapan #yapcrejectcon

この記事はPerl Advent Calendar 2025 15日目の記事です。

YAPC::Fukuoka 2025非公式リジェクトコンを開催しました

smarthr.connpass.com

SmartHRさんに会場を貸していただき、私が所属するカヤックと共催という形でリジェクトコンを行いました。

これの発端は、私がプロポーザルを応募していたYAPC::Fukuoka 2025のLTが落ちてどこかで発表したい!と言っていたところ、id:magnoliakさんに発言を拾っていただいて、色々準備をして開催にこぎつけた形でした。Magnolia_kさん並びに会場を貸していただいたSmartHRさん並びにinaoさんには感謝します。

発表していただいた方々もバラエティ豊かで、YAPCの余韻を感じられる会でした。また、papixさんをはじめとしたYAPC運営の方にもきていただき話を聞く場も設けて、今年のYAPCは面白かったな、来年のYAPCが大変楽しみだな!という会になったかと思います。

来年のYAPCまで1年近くありますが、それまでYAPC熱を下げないためにも何らか運営の方と協力してイベントをやっていけたらなと思います。

perlをWebAssembly上で動かすと何が嬉しいの???」というLTをしました

speakerdeck.com

スライドはこれで、デモで作ったゲームはこちら。

perldrop.maco.pics

これサイズもエグくてwasm部分だけで60MBあります。wazeroとperlコマンドがそのまま乗っかってるのでしょうがないね。

とはいえこういうユーザーコードが安全に実行できるとか、ブラウザ上で動くと言うのがWASMのいいところ。夢が広がりませんか?

じゃあどうやってzeroperlビルドするんですか、手に入るんですかみたいな話はまた別の日のAdvent Calendarでします!ではでは〜

YAPC::Fukuoka 2025でコーディングエージェントが成立するまでの歴史について話しました

YAPC::Fukuoka 2025に行ってきた

yapcjapan.org

ブログを書くまでがYAPC。どうもmacopyです。YAPC::Fukuokaに行ってきたので報告です。やっぱりYAPCは最高ですね。運営の皆様、スピーカーの皆様、参加者の皆様、お話ししていただいた皆様ありがとうございました。

簡単にまとめます。

0日目

前日に降り立ち、デルタさんの非公式前夜祭にお邪魔しました。そこで僕が行うトークの宣伝みたいなことをさせていただいたり、他の方のトークの宣伝を聞いたりなど大変良かったです。ちょっと体調が悪く明日に備えてビールは控えさせていただいたのですが、大変良さそうなビアバーだったので次回はビールを飲みいきたいと思います。デルタさんありがとうございました。

1日目

さて会場ですが、今回は福岡は福岡工大です。前回のはこだて未来大そうでしたが、大学で行うのはなんだか良い気がします。1日目は学食でしたが、一周回ってフレッシュな気分です。2日目はトラックを行う会場によって違う建物になっていましたが、そういったキャンパス内の移動も昔懐かしい気分になりました。

僕のトークはこの日の午後だったので、それまで気が張り詰めていて、逆に集中力が上がってきけていたのですが、自分のトークの後はぐったりしてしまって記憶が曖昧です。いくつか覚えているトークの感想を簡単に。

さてこの日の終わりには企画LTがありました。どの発表も面白かったのですが、カラオケBanBanの方が行われたAIが見張り、人がもてなす — 全国400店舗のカラオケBanBanの運営をサポートするAI Agent by 西尾健人が印象に残っています。成り立っているビジネスをさらにAIで加速するのってシンプルに「強い」と感じました。

1日目のYAPCの後は特に公式の懇親会はなかった(U29と学生対象のはありました)ので、僕自身で企画して非公式懇親会を行いました。よくYAPCに行くと同窓会、なんて言っていますが、今回は本当に同窓会をしました。何かというとカヤックならびにそのOB・関係者を集めた非公式懇親会を同僚の実家(!)である博多の居酒屋で行いました。どんどん良い料理が出てきて良かったです。密な交流でした。

トークがあったせいかこの日もお酒は控えて、さっさとホテルへ。

2日目

ちゃんと起きて、最初のトークから聞けました。いくつか覚えているトークを紹介します。

  • ある編集者のこれまでとこれから —— 開発者コミュニティと歩んだ四半世紀 by 稲尾尚徳
    • 四半世紀というタイトルがすごい重みを感じるものの、inaoさんの淡々としつつちゃんと引っ掛かりがあるような喋り口でとても楽しめました。シンプルにinaoさんのような技術者をサポートしてきて25年の方がDevRelやっているSmartHRさんすごいなと思いました
  • Perl の生きのこり by わいとん & kobaken
    • Perlの話だしそんなに人いないかもだから(失礼)、聞きに行かないと!って思ったら結構人が入ってて驚きました。今回のYAPCPerlの話が以前より多めだと感じたのですが、Perlの話でも皆さん聞きにこられていて、それはそれで喜ばしいなと思いました。このトーク自体はPerlとWebが歩んできた歴史の話やこれからどう生きるかみたいな話でした。以前似たような話をしていたので、共感〜という感じです
  • *S Tech Talks
    • 踊り場で行われていたセッションです。yusukebeさんが司会をしつつSのつく話をアンカンファレンス的に会場の人が即興でやるみたいな感じ。僕はAnybatrossの裏側の話をしました。この話自体は12/1の会社のAdvent Calendarに出るので読んでみてね。他にも自分のライブラリの話をされている方のスターがどんどん伸びていくみたいなこともあって面白かったですね
  • Day 1 最速振り返り
    • これも踊り場のセッションです。その名の通り1日目に行われたトークについて、概要や感想を司会のonkさんや会場にいる人が述べるというもの。僕を含めて会場にスピーカー本人がいたら本人が説明するというのもありましたが、ここで直接自分のトークの感想をいただけるというのも感激でした。mizzyさんとgfxさんありがとうございます。
  • OSS開発者なら学生参加者いっぱい集められる説
    • 踊り場であったmoznionさんの謎のコーナー。元同僚のfujiwaraさんやSongmuさんなどの会場にいたOSS開発者を前にして、さらに学生さんも読んで、パネルディスカッション的なことをやるみたいな場でした。意外と学生さんいて良かったです。本当に集められるんだなあ
  • ステートレスなLLMでステートフルなAI agentを作る by 藤吾郎 (gfx)
    • AIネタということでエージェントを作っているというgfxさんのトークです。今gfxさんこういうことされているんだなという驚きと、僕自身が社内でRAGエージェントを作っていた経験も思い起こしてそうだよね〜という感じでした。また、マスコット的なエージェントだと記憶に対する取り組み方が違うなとも感じたのもこのセッションを聞いて得られた気づきでした

この後はLTとキーノートですね。LTで印象的だったのはサンリオの方がやられた伝統的日本企業のソフトウェアエンジニアになって無双しよう! by 倉井龍太郎で、前日のカラオケBanBanの例や、みられなかったのですがトライアルの方がやられていたセッションなど、ITがメインではない業態にIT技術を内製組織を作って取り組むというのが印象的でした。そういう人のトークYAPCでもっともっと聞いてみたいですね。

最後にキーノートでpyamaさんがこれまでのキャリアについて振り返る話を聞きました。これを聞いて自分は、自分に対してもっとブッコむとことでブッコまないと面白ことがあっちからぞとはっぱをかけたくなる気分になりました。YAPCをはじめとしたカンファレンスってこういうやる気にさせてくれる場だと思います。

その後はお開きとなり来年はビッグサイトでやるぞ!!とか、そういう話でクロージング。そんでもって懇親会会場に移りました。ここでやっと今回の旅で初めてお酒が飲めまして、ビアチキさんのビール美味しかったです。また、会場でトークの感想を言いに行ったり、感想のカツアゲをしに行ったりなどしました。カツアゲはスピーカーの特権です。みんなもYAPCで喋って感想をカツアゲしに行こう。

今回も大満足!次の日は完全に旅行ということで電車に乗って別府まで行き、温泉に入って帰りました。本当はホーバークラフトに乗りたかったのですが、時間の合う便がなくて乗れませんでした。どうやら大分空港から九州に入るような旅程を組めばいけそうなので、これはこれで別で乗りに行きたいと思います。

YAPCで喋ってきました

mackee.hatenablog.com

これをやりました。

speakerdeck.com

あとライブコーディングも行いました。完成品のコードについてはこちらに公開しておきます。

yapcfukukoka2025-road-to-agent · GitHub

ありがたいことに部屋が満席で、多くの方に見ていただきました。また、話した後も良かったよと言ってくださった方が多くいました。感謝を申し上げます。ブログ等で補足や感想を呟いていただけるとありがたいです。

今回のトークでなぜこういうトークをやるのか・自分はやりたいのかということを考えたのですが、一見難しそうな技術について自分で学習し、それを人の目の前でやってみせるというのが好きなんだなあと認識しました。

YAPC::Kyotoで行ったデプロイ手法の変遷、YAPC::Hiroshimaで行ったパスキーについての解説もそうで、やってみると実はこんな技術要素に分解できて、実装できるよみたいなことを言いたいわけですね。今回のAIエージェントも多くの人が少ない行数でちゃんと動くものができていると驚かれており、実際そんなに難しくないんだよという意図が伝わって良かったです。

この芸風でビッグサイトも何かできるんじゃないかと考えていますので、精進します。ちょっとこの芸風だとベストトークは難しいかもなと感じるところではありますが...。

YAPC::Fukuoka 2025でAIコーディングエージェントの起源と仕組みに関するトークを行います #yapcjapan

fortee.jp

っていうトークをします。

トークは前半と後半に分かれており、前半は論文を挙げながらどのようにしてコード生成タスクにReActが組み合わさり現在のコーディングエージェントとして練り上げられてきたかを語ります。

後半はPerlを使ってReActループを実装しながら、コーディングエージェントとして動かすまでをライブで見せていきます。どちらかというとスライドのコードを写経しながら解説し、動かすというのに近いかもしれません。

このトークが面白いと思ってくれそうな人

  • 普段コーディングエージェントを使っているが中身がどうなっているか興味がある
    • シンプルではあるものの意外と奥深いです
  • 2025年にいきなりコーディングエージェントが出てきたように見えている人
    • 実は時代の流れによって実用になったことがわかります
  • 自分でコーディングエージェントを実装してみたい人
    • 実装上の要点を実際にコーディングしている人を見ながらわかります

というわけで見にきてね

YAPC::Fukuoka 2025 は 11月14日(金)〜11月15日(土)の2日間で行われます。私のトークは14日(金)の15:25からTrack Bで行います。

yapcjapan.org

また、現地に来られない方のためにリアルタイム配信もあります。

blog.yapcjapan.org

私のトーク以外にもAIに関するトークや、その他面白そうなトークがたくさんあります。ぜひ見にきてください。また、応援したり質問してくれたり、面白かった!といってくれるとありがたいです。

では福岡もしくはオンラインで会いましょう!

今のClaude Codeは永続プロセスの管理ができる

さて過去にmcp-daemonizeなるツールを書いたが、今のClaude Code(具体的にはv1.0.71以降)はバックグラウンドプロセスの管理機能が入っている。

github.com

zenn.dev

github.com

なもんで、mcp-daemonizeは必要ない。ちなみにステータスバーには何個立ち上がっているかどうかなどが表示される。前はpkillやlsofなどを駆使してキルしていたし、ログも見れてなかったのでそれに比べると順当な機能が追加されていっているように感じる(とはいえ2ヶ月前の話だが)。

一方Codex CLIはどうかというと、issueはあるが機能はない。mcp-daemonizeを使用してください。Gemini CLIも同様っぽい(使ってないので自信がない。間違ってたら教えてください)

github.com

しかしmcp-daemonizeを使用していて思うのが、こういうツールはおそらくエージェントに統合されていた方が良い。というのもちゃんとバックグラウンドプロセスはmcp-daemonizeを使えと都度指示しないと使ってくれない。AGENTS.mdに書いても無視される確率の方が今のところ高い。シェルによるコマンド実行と同レベルのところにプロンプトが書かれてないとうまく機能しないと推察している。

おそらくLSPで関数シグネチャを探すだとか、フォーマットを書けるとかもこのようにエージェントと結合していないとうまく機能するのが難しい部分に思える。MCPでエージェントを拡張できると言っても、MCPで提供されるツールはfirst-classではないように思える。

大吉祥寺.pmに参加しました

Perl Mongerのmacopyです。pmということで大吉祥寺.pmに参加しました。下は本当に行った時・行った後に出た感情などを書いております。話されたトークの感想等は他の方のブログや、トークスライドを見ると良いでしょう。

感想

  • 大吉祥寺.pmは最近は設計に関する話や、エンジニアリングへの取り込み方など、言語やフレームワーク、レイヤー、特定技術に限らない話をされている方が多い印象だった
    • 国内pmの総本山たる(?)YAPC::Japan自体が近年そういう傾向にあった(独自研究)
      • というのは本当に印象で、京都・広島・函館のタイムテーブルを見返してみるそうではない。今度開催されるYAPC::Fukuokaでは特に幅広い技術そのものの話が採択されているように感じる
    • 私は別にこれが悪いと言っているわけではない。実際大事だ。一方で、技術的な具体の話も重要だ
    • 両方があったという意味・それが1トラックで行われていたという意味、大吉祥寺.pmがそれらの結節点になっていた
      • 1トラックというのは非常に重い意味を持つ。普通カンファレンスは3トラックなどのマルチトラックで開催され、同時に行われるトークセッションが複数あり、その中から好みのものを参加者が選んで部屋へ向かう。同じ時間に開催されているトークをどちらも聞きたいなんて思うこともあるが、興味がないトークを避けて別の少しでも興味があるトークに移ることができるのだ
      • 大吉祥寺.pmは、外に行ったりアンカンファレンスにでも参加しなければ、運営によって選ばれたただ一つのトークセッションを聞くしかない。興味がなくても聞かなくてはならない(外に出ればいいのだが時間を無駄にしている感覚は持つだろう)というのは、厳しい制約かつ、プロポーザルのタイトルや説明を読んでピンと来なかったトークも聞くという事象を起こす
      • 「自分で選ぶ」という行為はそれだけでバイアスを産む。あらゆるものがリコメンドエンジンによるエコーチェンバーになってしまっている現代、全く知らない分野の話を聞くには、非常に大きな本能から抗う能力が必要だろう
      • 大吉祥寺.pmは1トラックなので自動的に興味がない話を聞くことになる。結果、話が面白くなかったらしょうがないが、普段生活していては聞かなかったキーワードが得られたら儲け物ではないだろうか り、それはそれで大事な機能だと思っている
  • そういった端から端までなんでも受け入れるという雰囲気が吉祥寺.pmのコミュニティにはあると思う
    • ◯◯を知っている人、みたいな普通の勉強会・カンファレンスにあるコンテキストを共有しているからこそ、話が早いという感覚は大吉祥寺.pmだとない
    • 一方でそういったカンファレンスにない、知らない視点や身近ではないドメインの知見が得られると感じる
  • 人がカンファレンスに何を求めるかというのは人それぞれである
  • 廊下で開催されていたアンカファレンスで「今のPerl入門」というのid:anatofuz さんとやった
    • pmなのにPerlの話題が一個もないのは寂しいし、皆さんが普段の生活をしていると遭遇しない情報を耳にして欲しかったというのがあった
    • 現代のPerlのインストール方法や、最近入った機能などを紹介した
  • 私のトークはハードウェアやろうぜという話ではあるが、一つの裏のテーマがあった。WhyやWhatを期待する人に対してHowの話を聞かせるというものである
    • 吉祥寺.pmは直近では設計ナイトもやっており、またマネジメントする人される人ナイトも行っている
      • そういったコミュニティから来ていて、そういった話を期待する人が話を聞いている
    • こういう情報が前提にあると、「今!ハードウェアの話を始めるには」という話に耳を傾けてもらうには、まず「なんでハードウェアをやるのか」みたいな話から始めざるを得ない
      • Whyから始める思考がある人にまず合わせる
  • 一方で、ハードウェアもとい電子工作というのはLEDをチカチカさせて、で何?で終わる人が入門者の5割を占めるとされる(要出典)
    • 「自分が作りたいもの」を想像できていないまま道具について入門するからだ。それは良くて、道具に強い興味があると、それはそれで強い武器となる
    • じゃあハードウェアで作りたいものを思いついてから入門せよというのも酷な話である。なぜなら作れる範囲のハードウェアで何ができるかわからないからだ
    • なので今回のトークでは、SWEがどういう気持ちでハードウェアに取り組むか、そして手段を羅列し、それらの手段を使った具体的なユースケースについて解説をした
    • 生成AIだけだとわからない箇所を述べるとスライドにあるが、具体的には知らないとLLMに投げかけるクエリを書けない部分についてインスピレーションを得るような情報を提供するという感じだ
  • 現地並びにSNS上でも皆様から好評を得られて何よりです。聞いていただいて大変感謝です
  • 来年もぜひ参加したい。次はどうなるかな、どこでいつになるかな?

speakerdeck.com

AIコーディングエージェントが自ら開発サーバーを起動しログを見れるMCPを作った

github.com

表題通りなんですけれどこれです。

なぜ作ったか

最近ClineやCopilot Edits Agent modeなどを使用してAIにコードを書かせることが多いんですが、私の使い方では色々と不便が出てきました。

私の使い方というのは、

  • 設計は人間がやってMarkdownを書く
  • プロジェクトの初期セットアップも人間がやる
  • 設計とプロジェクトを読ませて、Memory Bankを作らせる
    • 最近ではMemory Bankとコンテキスト長やコストとの兼ね合いがあり、このやり方が良いのかは疑問がある
  • タスク分解を人間と壁打ちしながら行う
  • そのあとはAuto Approve(Read,Write,Safe Command, MCP)を有効にして自動運転

という感じです。ただ、自動運転中でも変な方向に行ったり、すごくハマっているようであれば、助け舟を出したり、チェックポイントを戻したりタスクを一からやり直させるなどしています。

自動運転をしている以上、デバッグもある程度AIがこなさなければなりません。またAIは人間側に言われないと実装確認をサボりがちです。実装確認というのは自動テストであったり、Webアプリであればブラウザなどを介した確認です。Playwright MCPをインストールしてその能力を持つのにも関わらず、サボりがちです。その一つとして、彼らは開発サーバーを起動する手段を持たないからでは無いか、というのが私の仮説です。

Clineなどのコーディングエージェントはコマンドをシェル経由で実行するツールを持っています。しかしこれらのツールは、エージェントがコマンドを実行し、コマンドが終了するまで待った上で、標準出力をエージェントに返します。つまり、vite devrails sのような長い時間実行するコマンドはClineやClaude Codeでは終了するまで待機していまいます。

そこでエージェントは人間に別のシェルで手動実行するように頼んでくることがあります。これでホットリロードの効いた開発サーバーで動作確認を行うようなユースケースでは解決できたように見えます。しかし、サーバーがエラーをログに出力しているケースでは、それをエージェントが見ることができません。当てずっぽうに修正を行ったり、人間にログを見るよう依頼をするケースもあります。ワークアラウンドとしては、ログを標準出力ではなくローカルのテキストファイルに出力するテクニックがあります。

ただ、エージェントも人間がやるデバッグ行為と同様、開発サーバーのログを見てやって欲しいと私は思いました。

解決方法

昨今さまざまなものが作られているModel Context Protocolに準拠したサーバーは、AIエージェントにさまざまな道具を与えています。今回は開発サーバーのような長時間実行するようなコマンド実行するMCPサーバーmcp-daemonizeを作成しました。

これは4つのツールをエージェントが使用できるようにします。daemonize_start daemonize_stop daemonize_list daemonize_logsです。

daemonize_startdaemonize_stopはその名の通りプロセスを起動します。このプロセスは注意点としてシェルを介しません。なので、シェル実行と同様の環境で行いたい場合はsh -cのように(エージェントが)指定する必要があります。またworkdirを指定する引数を必須にしています。これにより明示的にコマンドが起動すべき場所をエージェントが指定するようになってトラブルが避けられるようになってます。この辺りは私が他のMCPを使用する上でcurrent directoryを指定するような引数が欲しいと思ったので、このようになっているのと、エージェントが都度指定した方がうまくいくことが多いと開発中に経験したからこうなっています。

daemonize_listは起動中にプロセスのリストです。そして、実は最も重要な機能であると私が考えているのはdaemonize_logsです。人間はデバッグのために開発サーバーのログを参照することが多々あります。この能力をエージェントにも付与するものです。tail引数が必須になっており末尾何行かをとってくるようになっています。現在はログがオンメモリで保持され、1024行で切り捨てられるようになっています。

まとめ

まだこのサーバーを本格的に投入していないのでどうなるかわからんのですが、皆さんも使ってみてフィードバックしていただいたり、パッチも送っていただけると助かります。ちなみにコードはほとんどを私が自ら書き、プロセス管理周りだけ少しチャット上のAIと話して相談したぐらいです。しかしドキュメントとテストはAIにやってもらいました。

以上です。