本記事では、「OSS応援企画」として記事の最後に「応援ボタン」を設置しています。1回の応援につき、Findyが100円をOSS団体などへ寄付し、エンジニアの成長とOSSの発展を応援する取り組みです。開発者の想いや取り組みに共感した気持ちが、OSSの支援にもつながっていく、そんな前向きな循環をFindyは目指しています。「応援ボタン」は、1日1回まで押すことができます。記事を読んで「いいな」と感じたら、ぜひボタンを押してあなたの応援の気持ちを届けてください。今回はなるセミ代表の成瀬 允宣さんです。
また同じ指摘をしている。これは何度目だろう――。
AIコーディングエージェントの台頭によって、私たちの生産性は上がっています。Claude Code、Codex、Cursor、GitHub Copilot。こうしたツールを日常的に使っている方であれば、コードを書く速度が以前とはまるで違うという実感があるのではないでしょうか。
しかし、その陰で私たちはAIと向き合う時間が増え、以前よりもストレスフルな日々を送るようになっています。生産性が上がったはずなのに、なぜか疲弊している。メンタルヘルスが、いま開発者にとって直近の課題になりつつあるのです。
何が私たちを苛んでいるのでしょうか。根本にあるのは、AIの確率的な性質です。同じ指示を出しても、100回やって100回同じ結果にはなりません。従来のプログラミングでは、同じ入力に対して同じ出力が返ることが大前提でした。AIエージェントとの協働では、その前提が崩れます。毎回少しずつ違う結果が返ってくる中で、期待通りの出力へ導くために、私たちは絶えず軌道修正を続けなければなりません。
さらに、AIの記憶の問題がこの負荷に拍車をかけます。一度伝えたはずのことを、AIは忘れます。だから私たちは、同じことを何度も何度も伝え直さなければなりません。確率的な振る舞いに加えて、記憶が持続しないという二重の不確実性。その中で正しい方向へ導き続ける作業は、想像以上に消耗するものです。
このことが私をOSS活動に駆り立てるきっかけとなったのでした。
OSSに取り組む理由と原動力
実は私にとって、OSS活動は縁遠いものでした。
普段の業務に加え、登壇、書籍執筆、カンファレンス運営、そして最近は経営大学院にも通っています。限られた時間の中でプログラムを書くのであれば、OSS活動に費やすより業務を前に進めたほうがいいと考えていました。
貢献したいという気持ちがなかったわけではありません。ただ、それよりも目の前の仕事を片付けるほうが合理的だと思っていたのです。
その価値観を変えたのがAIでした。AIコーディングエージェントを本格的に使い始めたことで、開発の進め方そのものが変わりました。そして同時に、これまで感じたことのない種類の疲弊を経験するようになったのです。この疲弊こそが、私をOSSへと突き動かした原動力でした。
AIは私たちをすり減らす
「AI疲れ」という言葉を聞くようになりました。生産性が上がったはずなのに疲れている。その矛盾を言い当てた言葉だと思います。
確率的な振る舞いと記憶の問題は、概念としては理解できるものです。しかし、日々の開発現場でこれらが引き起こす具体的な苦しみは、概念の理解だけでは伝わりません。実際にAIコーディングエージェントと日常的に向き合っている方であれば、次のような場面に心当たりがあるのではないでしょうか。
言ったことをやらない。明確に指示したはずの要件を満たさずに、「完了しました」と平然と報告してくる。よかれと思って余計なことをする。頼んでいないリファクタリングを勝手に始めて、動いていたコードを壊す。一度教えたことをいつの間にか守らなくなる。最初の数回は指示通りに動いていたのに、会話が長くなるにつれて、取り決めたルールを忘れたかのように振る舞い始める。そして、平気でデグレを引き起こす。修正を加えるたびに、別の箇所が壊れていないか確認しなければなりません。
こうした問題の根底には、Context Rot――つまり、「コンテキストが腐る」現象があります。
昨今ではモデルによっては、AIのコンテキストウィンドウに100万トークン入るようになりました。しかし、100万トークン分の情報を正確に理解して一貫した振る舞いを維持できるかは別の話です。情報が入っているのと、その情報に基づいて正しく動けるのとでは、まるで意味が違います。会話が進むにつれてコンテキストの中で情報の優先度が崩れ、古い指示と新しい指示が混線し、結果として自らが生成したコードすら制御しきれなくなるのです。
このような状態で、良い結果を出そうと何度も試行を繰り返します。同じ内容の指摘を、同じ相手に、何度も何度も伝え直します。人間のチームメンバーであれば一度のフィードバックで改善が期待できますが、AIエージェントにはその前提が通用しません。
ここまでであれば、まだ耐えられるかもしれません。しかし、AIを活用した開発の厄介なところは、並行作業ができてしまう点にあります。自分が司令塔となって、複数のプロジェクトを同時にこなすことが物理的に可能になるのです。一人で複数のチームを率いているような状態です。
残念ながら、そのチームのメンバーは先ほど述べたような性質を持っています。鋭いコードや深い洞察を見せる瞬間がある一方で、書き出すコードが頓珍漢になる。そんなピーキーな能力を持った開発者を複数チーム分抱え、それぞれに細々と同じ指摘を繰り返すことになります。
質的な消耗に加えて、量的な消耗も重なります。多くのAIコーディングツールは定額制です。定額制というのは、使わなければ損をした気分になる仕組みでもあります。食べ放題と同じです。いくら食べたところで胃袋には限界があり、原価を超えるような食べ方は現実にはできないのに、元を取ろうとして無理に詰め込もうとしてしまう。AIツールも同じで、Rate Limitギリギリまで使わないともったいないという心理が働き、必要以上にAIを回し続けてしまうのです。
能力のばらつきに振り回される質的な消耗と、使わないと損だという心理に駆り立てられる量的な消耗。この二つが重なったとき、どうして精神を健康に保つことができるでしょうか。
私は、この状況を仕組みで解決しなければならないと思いました。そしてその仕組みを思いついたとき、正直に言えば恐怖を感じました。これは開発者の働き方を変えるものだと思ったからです。いまもっとも心地よいとされている開発のやり方を、根本から壊す発明になる。しかし同時に、いつかは誰かがこれを壊すとも思いました。ならば、どうせ壊されるのであれば、自分の手で壊そうと。
この覚悟が込められたOSSの名をTAKTといいます。
TAKTで守れ！ みんなのメンタルヘルス
TAKTがやることは単純です。私たちが消耗している作業――AIへの繰り返しの指摘、デグレの確認、要件を満たしているかの粗探し――を、別のAIに担わせます。つまり、もっとも私たちをイライラさせる根源をAIに解決させます。
この仕組みの核心は、実装者とレビュワーの分離にあります。AIエージェントが書いたコードに対して、別のAIエージェントがレビュワーとして徹底的に指摘を続けます。ひとりの実装者に対して、複数のスペシャリストの視点からレビューが延々と繰り返されるのです。人間がこの役割を担えば疲弊しますが、AIにとってはそうではありません。人間が何度も同じ指摘をする必要がなくなり、代わりにAI同士が改善ループを回し続けます。
TAKTはこのオーケストレーションをYAMLで記述します。この記述は誰でも書くことができ、共有もできます。さらに、私のプログラマとしての知見を反映したワークフローがビルトインで提供されています。TAKTをインストールすれば、私と同じ開発環境がすぐに手に入るのです。それは、AI疲れという病への特効薬になり得るのです。
OSSが次のOSSを生む
TAKTを開発する過程で、いくつかの技術的な課題に直面しました。それらの課題に対する解決策は、TAKT固有の問題ではなく、より広い範囲で役立つものでした。そこで、TAKTの内部処理として動いていたものを独立したOSSとして切り出すことにしました。
そのひとつが Faceted-prompting というアーキテクチャです。
AIコーディングエージェントを実用的に使おうとすると、プロンプトの管理が大きな課題になります。ひとつのプロンプトにあらゆる指示を詰め込んでいくと、すぐに肥大化します。肥大化したプロンプトは、どこを修正すればよいのかわからなくなります。さらに、プロンプトが複数に分かれている場合、一箇所を修正すると他のプロンプトにも同じ修正を加えたくなります。
たとえば、Claude CodeのSkillsのような仕組みを思い浮かべてください。フロントエンドのスキルとバックエンドのスキルがそれぞれあり、場面によって使い分けているとします。このとき、プログラミングの共通原則のように、どちらにも含めるべき知識があります。同時に、フロントエンドならではの知識やバックエンドならではの知識もあります。通常であれば、共通の知識はフロントエンドのプロンプトとバックエンドのプロンプトの両方にそれぞれ記述されます。では、DRY原則についてプロンプトに追記したくなったとき、どうするでしょうか。フロントエンドのプロンプトを修正して、次にバックエンドのプロンプトを修正する。この手順が煩雑なのです。
プログラミングの世界にはSSOT（Single Source of Truth）という概念があります。情報は一箇所で管理すべきだという考え方です。そうしなければ、いつか更新を漏らし、プロンプト間で矛盾が生まれます。もうひとつ、SOC（Separation of Concerns）という概念もあります。関心ごとに責務を分離すべきだという考え方です。Faceted-promptingは、この2つの原則をプロンプト管理に適用するものです。関心ごとにプロンプトを分離し（SOC）、共通部分を一元管理する（SSOT）ことで、肥大化と重複の問題を同時に解決します。
OSSをひとたび始めると、次のOSSへのハードルが下がります。TAKTという最初の一歩が、Faceted-promptingという次の一歩を自然に生み出しました。ものをつくる過程で課題が見え、その課題を解くことがまた別の貢献になる。この連鎖が、私をOSS活動へと引き込んでいったのです。
産みの苦しみと楽しさと得られるもの
本来であれば、ここでOSSのキラキラした楽しさを語るべきなのかもしれません。しかし、もともとの動機が苦しさであった以上、楽しさの方向にはあまり筆が進みません。綺麗事を並べるよりも、歯に衣着せず、素直な内情を吐露したいと思います。
もしかしたら、この見出しを見て、OSS活動を踏みとどまろうと思う方もいるかもしれません。しかし、それはこの記事を最後まで読んでから判断してほしいのです。苦しみを正直にお伝えします。その代わり、苦しみの先に得られるものも正直にお伝えします。フラットに、どちらも受け取っていただきたいのです。
それは誰かの苦しみでもある
OSSの苦しみの核心は、プレッシャーです。私はこのプレッシャーを、業務で開発しているプロダクトと遜色なく感じています。
なぜ遜色ないのか。それは、自分が提供したOSSに不具合があれば、誰かを苦しめるからです。その出来がいまいちであれば、誰かを失望させます。
業務のプロダクトであれば、チームがあり、テストがあり、リリースプロセスがあります。OSSでは、そのすべてを自分で背負います。自分の名前で公開しているコードが、見知らぬ誰かの開発環境で動いている。その事実の重さは、業務とはまた違った形で肩にのしかかります。
この強いプレッシャーは、健康にも影響を及ぼします。TAKTを産み落とした2026年1月23日以降のヘルスアプリをおそるおそる覗いてみたのですが、平均睡眠時間が1時間以上減っていました。数字で見ると、自分でも驚きます。
特に最初の一ヶ月は寝食をおろそかにして、延々と開発を続けていました。昼間は本業、夜はTAKT開発。
この生活が持続可能でないことは、頭では分かっていました。それでも手を止められなかったのは、先ほど述べたプレッシャーが裏返しの責任感として働いていたからです。自分のOSSを使ってくれている人がいる以上、止まるわけにはいかないと思っていました。
娯楽ではなく使命感で始めたOSS活動は、このような苦しみを伴うことがあるのです。
表裏一体の楽しさ
ここまで苦しみを語ってきましたが、楽しさがないわけではありません。むしろ、苦しみと楽しさは表裏一体です。
皮肉なことに、私がOSS活動を無理なく続けられているのは、AIのおかげです。この記事の冒頭でAIへの疲弊を語りましたが、AIとの付き合い方の解像度が上がった今、AIは私にとって強力な開発パートナーになっています。TAKTをつくること自体が、AIを自在に操る訓練になっています。
AIコーディングエージェントを使いこなすほど、できることの幅が広がります。最初は思い通りにならなかったAIが、プロンプトの設計やワークフローの工夫を重ねるうちに、意図した通りに動くようになっていく。これはまさにエンジニアリングであり、この過程がたまらなく楽しいのです。
しかも、その解像度の向上がそのままTAKTの改善につながります。AIの振る舞いをより深く理解するほど、TAKTのワークフローやファセットの設計がより洗練されていく。自分の成長がプロダクトの成長に直結する。この循環は、業務の開発ではなかなか味わえないものです。
この過程でひとつ、発見がありました。ほとんどの人はAIに「依頼」をしようとしています。指示を出し、結果を受け取り、不満があればまた指示を出す。しかし、私がTAKTで実現しようとしているのは、それとは根本的に異なります。自分の分身をつくり、代わりに動いてもらうのです。
人は多面的で、ひとつの側面では測れません。ひとつのAIエージェントが振る舞えるのも、その一面でしかありません。ならば、一面をひとつのAIエージェントとし、複数のAIエージェントで私を表現すればいい。フロントエンドを書くときの私、バックエンドを書くときの私、アーキテクチャを考える私、コードをレビューする私。それぞれの知識、判断基準、目線をプロンプトに注ぎ込み、複数の分身として振る舞わせる。
AIに仕事を頼むのではなく、自分自身のAIエージェントを召喚する。私はこれをサーヴァントエンジニアリングと呼んでいます。絶対に流行らないと思いますが。
そして何より、OSSは自分のプロダクトです。自由につくっていい。誰かの承認を待つ必要もなければ、組織の都合に合わせる必要もありません。自分のビジョンをそのまま形にできます。「こうあるべきだ」と信じるものを、妥協なく追求できる。この自由さこそが、OSSの醍醐味です。
打算なんて要らない
では、なぜそれでも活動するのでしょうか。
答えはひとつです。自分と同じ状況に陥る誰かを救いたいからです。
あなたが苦しいと感じている部分は、きっと誰かも苦しいと感じているはずです。私がつくったものが誰かの苦しみを和らげているのだとしたら、それだけで続ける理由になります。
そして、あなたにも同じことができるはずです。あなたが感じている課題を解決するものをつくれば、それは同じ課題に苦しむ誰かを助けることになります。
そこには打算など何もありません。人が誰かを救うのに論理は不要なのです。
実際に得られたもの
とはいえ、結果として得られたものがあります。
まず、ユーザーからの感謝です。直接お礼を言われることがあります。自分が書いたコードが誰かの役に立ち、その人がわざわざ感謝を伝えてくれる。開発者冥利に尽きるとは、まさにこのことです。
TAKTの更新を心待ちにしてくれている方もいます。新しいバージョンをリリースすると反応がある。自分がつくったものに期待を寄せてくれる人がいるという事実は、先ほど述べたプレッシャーの源泉でもありますが、同時に何よりの励みでもあります。
メンテナーになってくれた仲間もできました。ひとりで始めたプロジェクトに、志を同じくする人が加わってくれる。OSSを始める前の私には想像もつかなかったことです。
また、GitHubスポンサーで支援してくださる方がいます。この支援は、ありがたくTAKT開発用のLLM費用に充てています。TAKTは複数のAIをサポートする関係上、普段使いではないAIも契約して開発する必要があり、その費用は決して小さくありません。支援が開発を支え、開発がまた誰かの役に立つ。この循環が生まれていることに、感謝しています。
露出の機会も増えました。登壇の機会もそうですが、この記事だってそうです。多くの方に注目を受けることで、さらなるプレッシャーを拝受することで、大きなモチベーションにつながります。
そして、Faceted-promptingというアイデアそのものが、私にとって最大の収穫かもしれません。正直に言えば、TAKTよりも重要なものではないかとすら思っています。TAKTはツールですが、Faceted-promptingは考え方です。ツールは時代とともに陳腐化しますが、考え方は残ります。OSSをつくる過程で、ツールだけでなく、それを支える思想にたどり着けたこと。これは活動を始めなければ得られなかったものです。
これらはすべて、打算ではなく行動した結果として、あとからついてきたものです。
エンジニアとして、今に向き合う
私は普段、自らのことをエンジニアとは称しません。エンジニアという言葉の語源に敬意を払っているからです。軽々しく名乗れるほど、その言葉は軽くないと思っています。
しかし、今私たちを取り巻く環境の変化は脅威です。この記事で述べてきたような、AIとの協働がもたらす消耗は、放っておけば開発者の心身を蝕み続けます。
この脅威に立ち向かうために必要なのは、エンジニアリングの力です。課題を分析し、仕組みで解決し、それを共有する。私たちが持っているその力を、今こそ使うべきだと考えています。
エンジニアとして、この大きな時代の変化に立ち向かうために、あなた自身のアイデアを形にしてみてはどうでしょうか。
あなたが日常の開発で感じている不便や苛立ち。それはもう、OSSの種です。大きなものでなくていい。自分が困っていることを解決する小さなツールをつくり、公開する。それだけで、同じことに困っている誰かの助けになります。
OSS活動を続けられるか不安ですか。今はAIの時代です。AIコーディングエージェントを使いましょう。AIとのやり取りで疲弊しますか。ならば、TAKTを使ってOSS活動を始めましょう。その先で得られるものは他で得難きもののはずです。