編碼智能體改變 OSS 開發：peco 重構、3D 建模、開發迴圈與維護挑戰
コーディングエージェントで変わったOSS開発 ——pecoの改修から3Dモデリング、開発ループの整備とメンテナンスの課題まで
Go 開發者牧（lestrrat）以編碼智能體完成 peco 長期擱置的重構、修復 helium 放置逾 9 年的 bug，並開發 3D 建模工具。他指出，編碼智能體要有效，需建立涵蓋問題定義、實作與驗證的開發迴圈，並為 3D 建模等任務準備檢查工具。另一方面，AI 生成的 PR 和安全報告增加維護者的分流負擔，持續依賴代理服務亦帶來維護風險。
こんにちは、lestrratこと牧と申します。私は普段趣味でGoでミドルウェアやライブラリを書いています。直近では長年開発が停滞していたファジーファインダーのpecoを更新しました。また、JOSE（JWT/JWS/JWE/JWK）ライブラリであるgithub.com/lestrrat-go/jwx （以下、jwx）のv4と、XMLツールキットのgithub.com/lestrrat-go/heliumを、エージェントを使って大幅に作り直し、その後もメンテナンスにエージェントを使い続けています。
さらに最近は門外漢であった3Dモデリングに関連するGo製ツールもエージェントを使って開発しています。本サイトの3Dプリンタ連載で扱っている話題にもこれらのツールは登場しはじめています。
この記事では、私がOSSの開発・メンテナンスの現場でコーディングエージェントをどう使っているかを紹介します。「実際にやってみて困ったこと、手を動かしてみて何がうまくいき、何がうまくいかなかったか」という話なので、ひょっとすると私が知らなかっただけで、「もっといいツールがあるよ」という指摘もあるかもしれませんが、あくまで実践記録として読んでいただけると幸いです。
エージェントの登場で変わったこと。
GitHubがOSS開発者向けにCopilotを提供しはじめてくれたころからコーディングエージェントを触っていましたが、最初は 「少し性能のよい入力補完」くらいの認識でした。
その後Claude Codeなどが登場しはじめたころからキャズムを超えた感じになり、自分の開発プロセスに積極的に取り入れはじめました。私がこのようにエージェントを積極的に取り入れるようになった理由は、これまで手を出せなかった・完遂する根気が続かなかったことを実行できるようになったことに尽きます。
6年以上避けていたリファクタが完成した
pecoは私がGoを書きはじめてまもなかった2014年ごろにリリースしました。言語自体もよくわかっていないまま作ったのにそれなりに人気が出てしまい、うれしいやら恥ずかしいやらでした。
ですがよくわかってないなりに作ったコードは小さな負債がたくさんあり、お世辞にもメンテナンスしやすいコードとはいえませんでした。そんな中、pecoの根幹ともいえるTUIライブラリのtermboxが開発の終了を宣言します。実際にはその数年前から開発は停滞していたので、開発終了の宣言を待たずにtermboxから別ライブラリへの移行は考えていました。
しかし、小さな負債がたくさんある中でpecoの諸機能を壊さずに根幹のライブラリを移行するのは、リターンが少ない割に非常に面倒くさい作業でした。何回か手を付けていたものの、完遂するまでやる気を持ち続けるのは難しく、termboxの開発終了から6年、pecoは特にメンテナンスもされないまま放置されてしまいました。
ところがある日Claude Codeに「ライブラリを入れ替えて」と依頼したところ、ものの1、2時間で実装を終えてしまったのです。その後たまっていたPRも私と相談しながらすべて片づけてしまい、3年ぶりのリリースにこぎつけられました。
これがコードを作成するということに関してはエージェントに敗北を認めざるを得なかった最初の経験でした。
9年放置したバグが直った
heliumは、Goで書かれたXMLツールキットです。私はもともとlibxml2のGoバインディングを書いていたのですが、Cの世界と行ったり来たりするせいでどうしても使いにくく、パフォーマンスを出すのにも一苦労でした。そこで「そもそもlibxml2のコードをそのままGoに移植してしまえばよいのでは？」と思い立って手動で書きはじめたコードが、heliumの元になっています。
libxml2のGoポートは2015年末に書きはじめました。libxml2のコードを読み、何をやっているのか理解し、Goに書き直すという作業を繰り返していたのですが、バグにあたってしまい、2016年の頭には力尽きて開発を止めていました。
バグ自体はDTDの内部サブセットに書かれたパラメータ実体（%name;という形で参照されるもの）を展開すると、その先の内容が読めなくなるというものでした。コードを読んで入力ストリームの扱いが怪しい、という見当まではついていましたが、そこから先に進めませんでした。
このバグもエージェントに調査させたところ、するっと修正されました。私が最初にバグにあたり、"// TODO"と書いてから9年以上がたっていました。
3Dモデリングに手を出せた
もうひとつコーディングエージェントが出てきて変わったのが、自分に知識のない領域に手を出せるようになったことです。
私は3DPジャングルという連載をさせてもらっているとおり、3Dプリンティングも趣味の一つとしています。基本的にCADであれでもないこれでもないと考えながらモデリングするのは楽しい作業なのですが、歯車のようなよく使う部品に関してはコードから生成するほうがよいと感じていました。
そこで最初は手書きでCADツールのFusion向けのAdd-Inを書いていました。ギアの歯車の形をどう設計するのか紐解き、歯の数から歯車の直径を計算し、その生成処理をFusion Python SDKで実装しました。世の中には類似ツールももちろんすでに存在するのですが、細かい仕様でかゆいところに手が届かなかったので、自分で書くことにしたのです。
このAdd-In自体はちゃんと動いていたのですが、Add-In単体ではテストを走らせることができないため、最終確認は人間がFusion上で確認するしかないのが苦痛でした。そこで、エージェントを使ってこの開発プロセスを改善できないか検討しました。
最終的にはある程度のCAD機能をFusionとは別に持たないといけないことがわかったのですが、「幾何拘束をソルバで解く」「ソリッドボディが閉じているか確認する」のような問題をどう判定するかという専門的な知識を私はほとんど持っていませんでした。
そこでエージェントと相談しながら試してみたところ、今ではそれらの問題もあらかた片づき、Fusionでコードを走らせる前にかなりの確認をエージェントだけで終わらせることが可能になりました。
先の2つがやる気の問題だったとすれば、こちらは知識の問題です。どれも、AIツールがなければ手つかずのままでした。
実践してわかった開発ループの重要性
コーディングエージェントは本当にかなり頭がよくて、これからどんどん進化していくかと思いますが、本稿執筆時点では導入して指示を出すだけで開発がすべて自動化されるわけではないと感じています。色々やってみた結果、ユーザ側で開発ループを準備・確立することが重要だと考えています。
開発ループとは、我々がほとんど無意識に行っていることを明示的にしているだけです。問題を定義し、問題の解決方法を実装し、その問題が解決されているかどうか確認する。我々はこの3つを繰り返して（ループして）課題を解決しています。
コーディングエージェントはもちろん汎用の開発ループは知っていますので、一般的な課題であればそれを適用することで解決できます。ですが、ツールやライブラリの目的や、作者である我々のこだわりや好みによって、開発ループは少しずつ変わっていきます。これらをコーディングエージェントに勝手にわかってくれと期待することはできませんので、このあたりを用意するのが人間の責任範囲になるかと思います。
以下にいくつか私が実際に組み立てた開発ループについて紹介します。
エコシステムをまたぐツールのループ
jwxでは主に依存関係を減らすために、JOSEのコアを構成する部分と、オプショナルな機能やまだ策定中の仕様、JOSE本体とは関係ない便利ツールを別々のモジュールとして実装しています。例えばes256k(secp256k1)は一般的なWeb向けの用途ではなくおもに仮想通貨に使われるため別モジュールですし、PQC対応のHPKE RFCの実装も本稿執筆時点でまだドラフト状態ですので別モジュールになっています。つまりjwxはモジュール一つを提供しているわけではなく、エコシステムとして提供しているわけです。
単体のモジュールだったらその中のループだけで完結すればよいのですが、このようにエコシステム全体として機能する場合はエコシステム全体に対してループを回す必要があります。jwx本体に変更を加えた場合、付随するほかのモジュールも本体の変更に追随する必要がありますが、これらを明示的にエージェントに指示するのは現実的ではありませんでした。
そこで、変更を入れた場合はエコシステム全体に対して簡単に確認を走らせることができるよう、ループを作りました。具体的には jwx本体の開発をしているときに、.companionsというディレクトリに付随モジュールを配置し、本体に変更があった場合、ルールにしたがってそれぞれの付随モジュールの確認もできるようにしました。これにより、jwx開発中に付随モジュールの確認・変更を指示しやすくなり、「機能Xを実装しろ」「変更を入れろ」という指示でも付随モジュールまで確認する流れを半自動的に組み込めるようになりました。
このように関係性を組み込むことにより、その後の開発ループを回す際に悩まなければいけないことを一つ減らせました。
検証ができない、というハードルを乗り越える
世に多くの「AIに命令をしたら3Dモデルを作ってくれた」という情報が出回っていますが、自分がやりたい分野ではまだこれが現実的な時間内に期待する成果ができたことがまだありません。以前連載記事に書かせていただきましたが、少なくとも私の検証ではいまだに傘歯車を正しくFusionに出力させることができていません。
そんな中私としては指示を出して自分の意図する正確なモデルをエージェントに作らせたいとかんがえています。同じものを何回も生成できるようにしたいので、最終的にはFusionなどのCADツールにモデルを生成するプラグインを生成したいのですが、 エージェントにこの開発を行わせるにはエージェントにプラグインコードを生成させ、その後それが正しい成果を生むか検証し、だめならまた生成を繰り返す、というループをまわさなければいけません。
FusionはGUIなので最初は自分がGUI上でプラグインをリロード、実行し、結果を検証するという行為をしていました。でも前述のようにプラグインコード（テキスト）を生成したいので、できればCLIのエージェントで開発を完結させたいですよね。つまり、CADのプラグインを作りたいけれど、CADを使わずにプラグインの確認をしたい。どうすればよいのか。……そうですね、自分でCLIで動くCAD相当のツールを作ってしまえばいいのです。（※ 本当の意味でのCADエンジンは作成するのが異常にコストが高いため、CADエンジンはスクラッチからは書かず、ライセンスするのが習わしです。ここではあくまで今回の目的に沿うCADに近しいものを指しています）
CADでは基本2次元の図面と3次元のボディを組み合わせてモデルを作成します。図面は勝手に位置や長さが変わってしまわないように「完全拘束」という状態を目指して作図するので、自分の与えた仕様から作られたロジックが完全拘束された図面を生成するかどうか確認できるツールが必要となります。3次元のモデルでは、ロジックが仕様に沿った形を生成しているかを確認します。例えば、指定したボディ同士が結合しているか、別々のボディとして存在しているか、といった確認が必要です。
これらをエージェント経由でUIから操作して確認するとなると、ボディの結合状態などは視覚的な観点からのみ確認することになり、正確な解析ができません。そうなってくるとヘッドレスなツールが必要となってきます。コーディングエージェントが登場する前ならここであきらめてしまうところですが、エージェントがあるのであればそもそもそのツールをエージェントに作ってもらえればいいだけのことです。
私はこの検証のためにdecad（3次元）、sketch（2次元）というモデリング用のモジュール・ツールを含むいくつかの3D関連ツールを作りました。これらをループに組み込むことによって開発ループを閉じ、効率的に開発を進めることができました。逆にこのような特殊な用途においては検証用のツールをユーザが用意しないと、エージェントが自ら生成したコードの内容を検証できませんので、無駄なトークンと無駄な時間を使ってしまう結果になります。
また、より複雑なモデルを実現してもらう際に、検証用のツールがそろっていることによってエージェントがより高い確率で目的を達成できるようになるのも確認しています。前述のFusionプラグインでは、最初は私が正解となるコードを手で書いていた平歯車でさえ、エージェントから正しい出力を得るのに何日もかかっていました。しかし、検証用のdecadやsketchを含むループを確立してからは、人間が1行もコードを書かずにプロンプトからサイクロイド減速機やリボン型のギアなどをかなり素早く正確に作れるようになっています。
このように、効率よくエージェントで開発するにはエージェントにただ毎回指示を与えるだけではなく、エージェントが開発ループを回せる環境を作ってあげるのが最も重要ではないか、という結論に達しました。
AI時代のOSS開発
ここまではどういう風に開発環境を整えているか、という話でしたが、次はむしろ私が作るOSSコードそのものが変わった点について紹介していきたいと思います。
技術が変わると（自分も含めた）それを取り巻く人々の期待値も変わっていきますし、OSSというコードの特殊性もあいまっていくつかやりかたを変える必要がありました。自分だけでなく周囲もエージェントを使うようになれば、必然的にOSSで提供するソフトウェアの内容も変わらざるを得ません。
AIレビューに耐えうる形にする
任意のソフトウェアを使うかどうかはこれまで人間の感覚で決められていました。今後はその役をAIが担っていくことになります。ですので、AIに見つかってしまうような突っ込みどころを残さない、というのは重要になっていくと考えています。AI時代ではブログなどの口コミが書かれることも、ユーザがそれを読みに行くことも減るうえ、OSSでは広告を打つなどのマーケティング施策を行うわけにはいきません。AI時代のSEOに近い感覚かと思います。
そこで定期的にAIに敵対的レビューを行わせてAIがどう思うかを確認しています。特にUX視点、およびセキュリティ視点でのレビューは重要視しており、jwxのようなツールにおいては手が空くたびにレビューを走らせたり、オンライン版のAIに評判や「〇〇用途に適しているか」などの確認をしています。
エンドユーザーがAIを使っている時代にはAIが見て選んでくれるソフトウェアである必要があるのです。
エージェント向けの手引きを同梱する
AIレビューに付随する項目ですが、AIが私の提供するOSSツール・ライブラリの使い方を理解できないと評価が下がってしまいます。もちろんこれまでも人間向けにドキュメント類を整備するのは重要でしたが、エージェントで開発する時代にはエージェント向けのドキュメントが必要です。
3Dモデリング用のコードではFusionのPython SDKの使い方をエージェントが知る必要がありました。Webサイトなどももちろん存在するのですが、エージェントに毎回検索させるのは効率が非常に悪いですし、目的のAPIが見つからないということもありました。そこで事前に実際のコードをインデックス化させて検索可能にしたところずっと早く効率的にコードを生成できるようになりました。
今後のOSSツール類も上記と同様にエージェントが自律的に正しい使い方を発見できるようにすることで利用される可能性が高くなると感じています。jwxでは検索ツールこそ設けていませんが、かわりにAI向けのドキュメントを同梱し、エージェントがCLAUDE.mdなどに到達さえできればどれが開発者用のドキュメントでどれがユーザ用のドキュメントかわかるようにしてあります。さらにjwx-guide-v4というスキルも同梱してv4のAPIをどう使うか、どこを参照して裏を取るか（利用者のGoモジュールキャッシュ、pkg.go.dev、リポジトリのドキュメント）、どこに落とし穴があるかを参照できるようになっています。
ライセンスの考え方
私がメンテナンスしているコードには主に2種類あって、一つはなんらかのRFC・基礎技術仕様をGoで実装しているもの、もうひとつは3Dモデリングのようにただひたすら自分の趣味でこういうものがあったらいいな、と思って作っているものです。
これらのうち、JOSEやXMLのような基礎技術仕様を実装しているものに関してはこれまでもずっとMITライセンスを使っていました。これらの基礎技術は私が実装しなくても誰かが実装しますし、私は自分の実装はよいものだと思っていますので大きな仕組みの中でぜひこれらを使ってほしいとも思っています。ですので、これらは今後もMITライセンスで公開し、個人であれ世界的な大企業であれ使えるようにしています。
3Dモデリング系のツールに関しては少し違う考え方をしています。ヘッドレスなCADツールはFreeCADのヘッドレスモードなどで提供されていますが、私が欲しいのは既存のCADツールをヘッドレスで操作するものではなく、生成するコードの整合性の検証を行うものです。また、将来的にはほかのCADでも同じような処理をしたいとも思っています。私の知る限り、そうした用途を満たすツールはほかにありません。
これらのツールはもちろんほかの人に使ってほしいと考えて公開しているのですが、（可能性はかなり低いですが）万が一大企業のワークフローにしれっと使われてしまった場合や、ほかの人が使っているエージェントにしれっとコピーされてしまった場合などを考えるとあまりいい気がしません。
そこで、sketchとdecad、また今回はちゃんと触れていませんが関連ツールのsolidlensに関してはMITライセンスではなく、PolyForm Noncommercial License 1.0.0で提供・公開しています。このライセンスでは、非商用目的での利用や、慈善団体・教育機関など所定の組織による利用が認められています。商用利用向けの有償提供は、このライセンスとは別の条件で行うことになります。というわけで、本稿ではOSSの文脈でこれらのツールを紹介していましたが、sketchとdecadに関しては実はOSSではなく、Source Availableなのでした。
エージェントに書かせてるコードですので、それらにOSSでないライセンスをつけることに関しては様々な意見があるかとは思いますし、たかだかライセンスを変えたところでそれが効果を発揮するかは怪しいとも思います。これが正しい答えかはわかりませんが、OSSにかかわるものとしては今後もライセンスについては考え続ける必要があると思います。
エージェント時代のOSS開発の悪いところ
ここまでエージェントを活用した開発の個人的な移り変わりをみてきましたが、弊害も感じています。
AIがないと… 困る
まず最大の問題としては、エージェントすなわちそのプロバイダへの依存でしょう。ほかの部分でも触れていますが、ほかの人がエージェントを使っている中、OSSメンテナンスをエージェントなしで行うのはなかなか難しいものがあります。
幸いにも私はある程度以上利用されているOSSのメンテナのため、Claude for Open SourceとCodex for Open Sourceを利用していますが、これと同じだけの処理能力を自腹で賄おうとしたら大変なことになります。
実際、本稿を書いている途中に、利用させてもらっている両方の支援プログラムの利用期限が切れ、使えなくなってしまいました。短期間なら両社のサブスクリプションを支払うことはできますが、継続的にこれを行うのは無理です。したがって万が一これらのプランを継続できないとメンテナンスも継続できないということになります。
エージェントがないとやれないというのはOSSメンテナの怠惰に聞こえるかもしれません。これまでも自分の知恵と努力で行ってきたことをやればいいというかもしれません。しかしメンテナ側から見ればコーディングエージェントは、これまでメンテナが自分の時間や費用を持ち出して支えてきた活動に降りてきた福音ともいうべきものです。さらに、ほかの人はエージェントを使っているわけですから、そのエージェントが見つけてきた脆弱性に対応する必要もあります。こうした脆弱性に今後エージェントなしでメンテナが一個人として対応するのは加速度的に難しくなるでしょう。
もちろん、安めのプランを使う、ローカルLLMを使う、などのオプションはありますが、開発者側で行わなければいけないこと（もしくは用意しなければいけない機材）が増えます。OSSのメンテナンスは個人のスキル・気力・財力に頼ってはじめて成立するシステムです。エージェントの登場によってできることが増えても、そのエージェントが使えなくなれば、それ以前の状態に戻ってしまうかもしれません。最悪の場合、ほかのエージェントを使っているソフトウェアに比べて、相対的に悪い状態になってしまうことも考えられます。
判断の難しいところですが、個人的にはOSSを使っているプロジェクト・企業からなんとかうまい方法でこれらのインフラストラクチャに対するサポートをしてもらえる仕組みが今後生まれてくればな…と期待しています。
また、私はまだそう感じていませんが、コーディングエージェントにコードを書かせてOSSの一番面白い部分を自分でやらなくなると、メンテナンスのモチベーションがわかなくなることもあるでしょう。そういった問題は今後エージェントの進化とともに少しずつ対応していくしかないでしょう。
プルリクエスト・セキュリティレポートとの付き合い方が変わる
もうひとつの悪い点は、誰もがAIを使ってPRやレポートを作れるようになり、それらへの対処が必要になることです。
jwxでは、これまで1年に1回あるかないかだったセキュリティ関連のレポートが、最近3か月の間に6件届きました。元が少ないので大した量に聞こえないかもしれませんが、一人でプロジェクトを回していると、明らかにAIが生成した長いレポートに目を通し、対応すべきかどうかを決めるのは精神的になかなかつらいものがあります。
というのも、まとはずれなセキュリティ関連のレポートも多いのです。例えばある正規表現に開始アンカーをつけないと、意図しないURLにアクセスできてしまう… というレポートが来たことがあります。指摘された挙動自体は確かにそのとおりです。ただ、この正規表現はユーザが任意で指定する引数で、アクセスできるURLを制限するために使うことも明記されています。つまり、ユーザがその用途と正規表現の挙動を認識したうえで指定する前提なので、これはコード上の問題ではなく、意図的なデザインなのです。
しかしAIはそこまでコンテキストを理解しないで「ここに問題があるかもしれません」とレポートし、それをさらに「これは最もクリティカルなレベルのセキュリティ上の問題である」として報告してくるユーザがいます。これらのトリアージにメンテナの限りあるリソースが使われてしまいます。
私が管理するコードに依存しているのは、たかだか数千のプロジェクトですが、それでもこうなので、もっと大きなプロジェクトでは相当大変なはずです。AIがコンテンツを作ってくる場合、そこに労力がいらないのでこのような問題が起こってしまうでしょう。
同様にPRもAIが作るようになって久しいです。私も実際、ほかのプロジェクトに送るPRをAIで作ることもあります。そして残念ながらPRも前述のセキュリティ問題の報告のように問題の芯をとらえてないものが多くなっているように見受けられます。
実はここ半年ばかり、いただいたPRをそのままマージするということをしたことはほとんどありません。PR自体のクオリティはそこまで低いわけではないのですが、よくよく見ると報告されている問題の一側面しか解決していないことが多く、そのまま取り込むことができないのです。ユーザが直面した問題そのものは修正されていても、UXの面でバランスが取れていなかったり、メンテナンス性を考えていなかったり、あとで見たときに後悔しそうなPRでは結果的に私がPRを作り直すことになります。
憶測ですが、これらのPRではエージェントに狭義の問題点の修正しか指示していないのでしょう。UXのバランスまでユーザに求めるのは酷な話かもしれませんが、セキュリティ問題と同じで、トリアージにはやはりリソースを取られてしまうのが大きな問題です。
さらに、人間が自分で書いた報告ならもう少し対話を試みるのですが、明らかにAIに書かせたPRではそこで協議するモチベーションはあまりありません。そこで最近はPRをもらっても、基本的にはイシュー報告を受けたのと同じ、という認識で対処しています。すなわち、PRのコードはあくまで参考であって、実際にはこちらで書き直してUXなどの側面からレビューし、自分がPRを新たに作る、という形にしています。これまではこのような書き直しはコストが高かったのですが、こちらもエージェントを使えるならコストは低くて済みます。
昨今あちこちで聞きますが、このように人間同士のコラボレーションツールとしてのPRは成立しなくなってきている、という感覚です。ですので、最近は新しくリポジトリを作っても外部からのPRは受け付けない設定にしています。イシューの報告は今後もウェルカムなのですが、コードはどうせ書き直すことになるので結構です、という感じです。
今後のOSSとAI
正直今後どうなっていくのかはわかりませんが、もはやAIなしでOSSをメンテナンスするのは難しい、というのが個人的な意見です。ただ、最初に述べたように、3Dモデリングに手を出せたのも、ずっと開発が停止していたプロジェクトを完走できたのも、AIとコーディングエージェントのおかげです。今後も、自分の実現したいことを最小限の手間で現実のものにできるでしょう。
私はインターネットが最初に一般に出回りはじめたときに20歳前後だったのですが、あのころは雨後の筍のようにWebサイトとも呼べない稚拙な仕組みのものが作られていました。そして自分でも作っていました。今コーディングエージェントを使った仕組みはそれくらいのレベルのものだと思っていますので、またそのうち当たり前になるのではないでしょうか。
OSSという概念は変わっていくかもしれません（というか、変わらざるを得ないとも感じています）。しかしそれに準ずるものは今後も存在し続けると思いますし、私は今後も創造的な部分以外では積極的にコーディングエージェントを活用してOSSないしそれに準じたコードを公開していくつもりです。人間はこれまでも面倒くさいことを機械やコンピュータに移譲してきましたし、きっとうまいところで折り合いをつけられるのではないかと思います。
個人的には今後も、AIとコーディングエージェントを便利に使っていきたいと考えています。皆さんも自分にあった使い方を探してみてください！
來源：gihyo.jp · gihyo.jp