ぱいぱいにっき

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

2025年の振り返りと2026年の抱負

2025年は変化の年でした。皆様いかが年末をお過ごしでしょうか。2025年と2026年の振り返りをしていきます。

前回

mackee.hatenablog.com

登壇とイベント

湘.なんか #2

speakerdeck.com

ライブコーディングという芸風？を確立させたいという意図もありつつ、自作フレームワークの自慢という話も含めたトークをした。tanukirpcはこの後の大AIコーディング時代にも大活躍していて、作って良かったなあというものです。またライブコーディングする機会も社内外で多く、2025年はライブコーディングを持ちネタとして認識できたと思えます。

湘.なんかや湘南.pmといった湘南鎌倉地域のITイベントも盛り上げていきたいですね！　あ！Kamakura.pmは2月末あたりに開催予定です。

Houtou.pm #1

speakerdeck.com

RailsのDHHが提唱したONCEモデルを見て、あれ、俺が今やっているのってこれに向かってる？と思った次第の話です。RailsはDockerに閉じてますが、Goなら言語自体がマルチプラットフォーム向けにビルドでき、最近は実行バイナリ内にアセットも簡単に含められるので、それを利用してポータブルなアプリが作れるよねという提案です。

意外と反響があり、ブクマ数でいうと今年一番見られたスライド・記事でした。

アナグラさんが開催しているHoutou.pmはこれが初開催ですが、このあとも精力的に開催されています。甲府という行きやすい立地かつ、ちゃんと地方に来た感じがするのでお得だなと思います。また甲府の周辺のITコミュニティもアツいと感じました。また行きたい！

大吉祥寺.pm 2025

speakerdeck.com

ソフトウェアエンジニアがハードウェアを始めるのに今が一番いいのではという話をしました。あとUSB-PDを利用するなど今時っぽい電子工作の話もしました。

大吉祥寺.pmはしゃべる前はアウェイだな〜とか思ってたんですが（失礼すぎる）、みんな暖かいし、全員の満足度を上げるような施策がたくさん用意されていて、素直にすごい！って思いました。あとワントラックなので、みんな僕のトークの感想を言ってくれます。めちゃめちゃ良かった...。なんらか恩返しをしたいですね。

mackee.hatenablog.com

YAPC::Fukuoka 2025

speakerdeck.com

AIエージェントの仕組みを論文を上げながら解説し、その後にライブコーディングを行うというトークをしました。結構危ない場面もありましたが、うまいことライブコーディング感が出たかなと思います。

mackee.hatenablog.com

そして何よりYAPC::Fukuokaがよかったですねえ。ええ、よかった。どのトークも面白いし、技術に対して皆さんリスペクトがあり、未知のものに対しても耳を傾ける暖かい場だったと思います。来年はビッグサイトに戻ってきます。どんな話が良いでしょうか。考えています！

YAPC::Fukuoka 2025非公式リジェクトコン

speakerdeck.com

YAPCのLT落ちてどっかで話したい！ってわがままを言ってたら吉祥寺.pmのオーガナイザーであるMagnoliaさんに拾ってもらって、一緒に開催したリジェクトコンです。YAPCではAnybatrossというWeb上のイベントを行なって公開していたのですが、そこで使ったzeroperlについて紹介しつつ、ユースケースを紹介するというトークを行いました。ウケてよかった。

リジェクトコンもSmartHRさんの会場提供など、さまざまの方の助けがあって行えました。またちょっとアドリブ気味でしたが、運営の方に話を聞くコーナーも用意できてよかったです。パネルの司会みたいな役も勝手にやりましたが、なんとか出来ていたでしょうか？　最近社内でも司会業が多い気がします。緊張したり、あーもっと上手くできたなーと思うこともありますが、楽しいのでもっとやっていきたですね。

仕事

この1年は2024年の後半と同じく、割と自由な立場で、社内でWebアプリ作って使ってもらったり、そのメンテナンスをしたりなどして暮らしていました。

前半はWeb技術で社内で使うサイネージ的なものを作っていたりしていましたが、後半はAIを使ったWebアプリ作成のワークショップをしたり、社内の技術者のお困りごとを聞く会をしたりとか。まあいろいろやってました。どういう仕事しているの？　と聞かれると説明しずらいのですがそんな感じです。社内事例でこれは！と思ったものがあったら、ぜひ外に出していきたい所存ではあります。

AIによる変化

今年の頭はCline、それ以降はClaude CodeとCodex CLIを併用した生活をしています。Clineを比較的早い時期に試して、ある程度限界はありつつも、使い方さえ間違えなければ力になると確信して以降、積極的に開発に活かしています。4月の段階でClineを使ってバックエンドを実装したサイトをリリースしています。

AIは力にもなり、毒にもなると思います。うまく利用すれば素早く頭や仕様書としてあるものを実現できるものの、あやふやな状態からではうまくいかないことも多いです。やらせたコーディングの結果、使えなくて捨てたことは何度もあります。

僕は今まで作りながら仕様を考えたり、設計を考えるような書き方をしてきましたが、今年は書く前・書かせる前から仕様と設計を考えなくてはなりません。そこは明らかに仕事のやり方が変わったと言えます。

来年はもっと加速するでしょうし、よりその場限りのアプリケーションが身の回りに進出していくと思います。最近Just in Time Softwareという概念を提唱する記事を見ました。まさにこれが進むと考えています。僕が社内で展開している、AIで作成したSPAを共有するアップローダーのような物があるのですが、そこに僕がアップロードして社内でヒットしているアプリケーションがあります。「画像赤入れ君」と言います。

画像赤入れ君はその名の通り、クリップボード上にある画像に対して四角い枠や矢印、文字でアノテーションを行い、クリップボードに戻すアプリです。PhotoshopやSkitchを起動すればできるタスクですが、これらのソフトウェアは必要以上の機能があり、また起動する手間があります。Slack上で見ているWebページなどに修正などを出すなどの特定のユースケースでうまく機能する小さいアプリケーションが画像赤入れ君です。

このような特定の仕事をうまくやるような小さなアプリがAIによって簡単に作れます。今まではソフトウェアとはしばしば作る人と使う人が分離しており、それによって生まれる引っ掛かりがありましたが、AIによって作る人と使う人が一致する状況が多くあります。社内ではこういう行為がもっとスムーズにいくような活動をしています。

趣味

3Dプリンタ

イベントのところに書くべきかもしれませんが、JRRF 2025という3Dプリンタビルダーとユーザーや企業が集まるイベントに出展してました。

自分の身の回りでも今年になって3Dプリンタを買った方が多くおり盛り上がりを感じます。ただ、10年前からプラを溶かしてXYZでノズルを動かすという原理原則は変わっておらず、ただただここ最近はメーカーをはじめとしたプレイヤーがたくさん参入してきて、それによって洗練がされてきたと感じます。10年間見えてきて、10年間同じプリンタを改造し続けたからこそ見せられる物があるのではないかという感じで出してきました。案の定デルタ型は3Dプリンタ界ではかなりマイノリティなので、存在を主張していきたいと思いました。もし今宇宙人がやってきて現在主流であるカルテシアン・ベッドスリンガー・CoreXY方式を禁止された時に、3Dプリンタを動かしたいと人類思った時に駆けつけられるようにデルタを動態保存していきたいですね。

この後の改造としては、複数フィラメント切り替え機構の導入です。Pico MMUを導入しました。これでQRコードもうまくいくと思いきや、フィラメントカッターなしだと詰まりがちなので、今はデルタのエフェクター部にフィラメントカッターを導入するような改造を行なっています。

モータースポーツ観戦

などなどいきました。

Formula Eは雨でしたが、間近で見られて良い席でした

SUPER GTはキャンプエリアに宿泊して観戦しました

ラリージャパンは岐阜まで行って早朝から観戦しました

来年はF1も行く予定です。

万博

2回いきました。

入れなかったけれど、風で揺れてるのが見れてよかったnull2

万博は変な建築物がいっぱい見れて良いですね

2027年にある横浜園芸博は家から近いので頻繁に行くと思います。

コンテンツ系

  • 読み始めたマンガ
    • 葬送のフリーレン
    • 売国機関
    • ダンジョンの中の人
      • こういうメタ的なところを使ってやる話が好き
    • 薬屋のひとりごと～猫猫の後宮謎解き手帳～
    • 怪獣を解剖する
    • 明日の敵と今日の握手を
    • 天幕のジャードゥーガル
      • アニメ化おめでとうございます。期待
    • オルクセン王国史～野蛮なオークの国は、如何にして平和なエルフの国を焼き払うに至ったか～
    • サンキューピッチ
    • ダンピアのおいしい冒険
    • 野球・文明・エイリアン
      • 異世界転生(転送もの)で舞台が未知の惑星かつ友好的な先住民がおり、彼らと協力して野球場を作る（？？？）という話
    • 進撃の巨人
  • 読んだ小説
    • 老神介護
    • 文字渦
      • すごい読みづらい。おもしろい

来年の抱負

  • 仕事はどうなるかわからんなという気持ちが大きいので、うまいこと波に乗ればええなと思う。今はAIの波に乗るだけである程度は楽しく過ごせる
  • 3Dプリンタ活動をメインに物を作る活動を続ける
  • 勉強会・カンファレンスはもう少しコンフォートゾーンから外れた場に行きたいと思う。TSKaigiなどに興味がある
  • フォーシーム100km/hは別件で肩を怪我したので来年に持ち越しです。リハビリとは別にジムに通い始めたので効果が出ると良いなと

本年中は皆様に大変お世話になりました。また来年、お会いしましょう。では

XS::Parse::Infix::FromPerlで勝手にパイプライン演算子を追加する

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

いつの間にか中置演算子を勝手に入れられるようになってたっぽい

一見するとPerlは原始時代から姿を変えていないシーラカンスのような言語だと思われるかもしれませんが、実は最近もいろいろ機能追加が続いています。しかし機能追加は安易にされているのではなく、ちゃんと検討や実験を経て追加されています。

実験ってなんぞやって思うかもしれませんが、実は今のPerlはかなり柔軟にキーワードなどを組み込める仕様になってまして。キーワードを追加するためのモジュールXS::Parse::KeywordのAuthorであるPaul Evansさんいわく

Perlの生きのこり - YAPC::Fukuoka 2025 - Speaker Deck

とのことなんで、Syntax::Keyword::**のようなモジュールをモリモリ作ってこうしたら言語が良くなるんじゃっていうのを示して言語に取り込んでもらうというサイクルが確立しているぽいです。

で、そう言うのを見てたら、XS::Parse::Infixと言うのを見つけました。あれ、中置演算子って追加できたっけと思いましたが、v5.38以降でこのモジュールは使えるみたいです。ほいならなんか面白いことできないかなと思ってこのブログ書いてます。

パイプライン演算子を追加してみよう

パイプライン演算子については以下の記事が詳しいです。

mametter.hatenablog.com

ある関数の結果を次の関数の引数に入れるみたいなやつです。Perlでやるとこんな感じかなあ。

[0..9] |> sub { [grep { $_ % 2 == 0 } $_[0]->@*]  } |> sub { [map { $_ ** 2 } $_[0]->@*] }

これで0から9までの数字から偶数を取り出し、それぞれの数を2乗するような数が出せるはず。普通Perlで書くと逆で、

map { $_ ** 2 } grep { $_ % 2 == 0 } (0..9)

こうなります。前から後ろに書く方が他の言語だと一般的な感じがしますね。ではこういうふうに使える |> 演算子を作っていきましょう。

環境構築

最近はaquaを使うのがお気に入りです。aquaが入っている状態で、

$ aqua init
$ aqua g -i skaji/relocatable-perl

これで最新のPerlが使えます。ビルド要らず！

XS::Parse::Infix::FromPerl

XS::Parse::InfixはXS、つまりPerlのC拡張として書かないといけないのがちょっとハードルが高いところです。しかしそんなあなたに朗報、このモジュールをPerlから扱えるようにしたXS::Parse::Infix::FromPerlがあります。今回はこれを使っていきます。

$ cpanm XS::Parse::Infix::FromPerl

それでは、書いていきましょう。

パイプライン演算子を使う

ここでは、pipeline.plというファイルを作成して以下のコードを書きます。

#!perl
use v5.42;
use utf8;

use XS::Parse::Infix::FromPerl qw(
    register_xs_parse_infix
    XPI_CLS_ADD_MISC
);

use Optree::Generate qw(
    make_entersub_op
);

BEGIN {
    register_xs_parse_infix "|>" => (
        cls => XPI_CLS_ADD_MISC,
        permit => sub { 1 },
        new_op => sub {
            my (undef, $lhs, $rhs) = @_;

            return make_entersub_op($rhs, [$lhs]);
        },
    );
};

use Data::Dumper;
my $arr = [0..9] |> sub { [grep { $_ % 2 == 0 } $_[0]->@*]  } |> sub { [map { $_ ** 2 } $_[0]->@*] };
warn Dumper $arr;

では解説していきましょう。

BEGIN {
    register_xs_parse_infix "|>" => (
        cls => XPI_CLS_ADD_MISC,
        permit => sub { 1 },
        new_op => sub {
            my (undef, $lhs, $rhs) = @_;

            return make_entersub_op($rhs, [$lhs]);
        },
    );
};

解説するにしてもここしかないんですが。XS::Parse::Infix::FromPerlが提供する関数はregister_xs_parse_infixのみです。これで定義します。他のコードの実行より前に定義して組み込みたいので、BEGINフェーズで定義しています。

一つ目の引数は演算子自体ですね。次にclsですが、ここに定義されている定数を指定します。多分演算子の優先順位とかに関わるかと思います。

permitオプションは、この演算子を許可するかどうかです。一旦ここでは1を返して許可。

で、new_opなんですが、ここは演算子の挙動を記述します。返すのはoptreeです。optreeっていうのはPerlの抽象構文木みたいなやつですね。この無名関数にはいろいろ渡ってくるんですが、2つ目と3つ目に演算子の左と右が渡ってくるので、それを使っていろいろゴニョゴニョするのが基本ぽいです。

で、make_entersub_opですが、これはOptree::Generateモジュールが提供する、関数呼び出しのoptreeを生成するシンタックスシュガー的なやつです。この場合、演算子の右側$rhsにはcoderefがやってくる想定なので、これを引数の一つ目にして、2つ目はこの関数に渡す引数なので、演算子の左側を渡します。

これで実行すると、

$ $ perl pipeline.pl
$VAR1 = [
          '0',
          '4',
          '16',
          36,
          '64'
        ];

ちゃんと動いてますね！

ちなみにスカラ以外の例えばリストなんかを渡すとセグフォするので、実用的にはもっと色々なケースを考えないといけなさそうです。

というわけで今回は、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

この記事は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の話だしそんなに人いないかもだから（失礼）、聞きに行かないと！って思ったら結構人が入ってて驚きました。今回のYAPCはPerlの話が以前より多めだと感じたのですが、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ではないように思える。