.jpg&w=3840&q=75)
本記事では、「OSS応援企画」として記事の最初と最後に「応援ボタン」を設置しています。1回の応援につき、Findyが100円をOSS団体などへ寄付し、エンジニアの成長とOSSの発展を応援する取り組みです。開発者の想いや取り組みに共感した気持ちが、OSSの支援にもつながっていく、そんな前向きな循環をFindyは目指しています。「応援ボタン」は、1日1回まで押すことができます。記事を読んで「いいな」と感じたら、ぜひボタンを押してあなたの応援の気持ちを届けてください。
初めまして。藤原 俊一郎（@fujiwara）と申します。
私は1998年にWeb業界（当時そんな言葉があったかも覚えてないですが）で仕事を始め、早いものでもう四半世紀以上が過ぎました。OSS活動を始めたのは2006年ごろのことです。当時流行っていたPlaggerというPerlで書かれたOSSのプラグインを自分なりに書き、その記事をblogに書き綴っていたのが最初でした。それが宮川 達彦さん（@miyagawa）の目に入り、blogにコメントをいただいて、当時の日本のPerl hacker達が集まるIRCに来ませんか?と誘われたことがきっかけです。その後は2011年に面白法人カヤックに転職し、そこでも当時の同僚がまさに息を吸うようにOSSをつくっていたため、自分も自然とそのようになっていったと記憶しています。
私のOSSの代表作は、Amazon ECSのデプロイツール ecspresso、AWS Lambda向けのlambroll、Terraformのtfstateを参照するためのtfstate-lookup、最近では現在勤務しているさくらインターネットが提供しているAppRun向けのデプロイツール apprun-cliなどがあります。ecspressoはおかげさまで開発を8年継続している間に大変多くの方に利用していただくようになり、GitHub Starsは1000を超えました。特に日本国内で、ECSのデプロイツールとしてはかなり有名なプロダクトになったと思っています。
「隙間家具OSS」という考え方
さて、私は自分のつくるものをよく「隙間家具OSS」と称しています。これは2017年ごろに言語化したのですが、自分がつくっているものは大きなものとものの隙間を繋ぐ、小さなソフトウェアだな、と自覚したことがきっかけでした。
OSSを語るときには、よく「世界を変えるプロダクト」みたいな話になりがちです。でも私がずっとつくってきたものは、もっと生活用品に近いものです。家具でいうなら隙間家具。部屋の主役じゃないけど、そこに“ちょうど収まる”ものがあると暮らしが快適になる。ソフトウェアでも同じで、大きなOSSやマネージドサービスを組み合わせるときにできがちな隙間を埋める小さな道具が、現場のワークフローを快適にすることがあります。
ecspressoはあえて全部を“やらない”
ecspressoの場合を考えてみます。ecspressoは「ECSのタスク定義とサービスのみ」を管理し、デプロイをとても便利にしてくれるツールです。ところが実際にECSでアプリケーションを動かすためには、ECSそのもの以外にも色々なAWS上のサービスを組み合わせる必要があります。ネットワークのようなインフラ要素やロードバランサー、ECSだけではデータを永続化できないので、データストアとなる他のマネージドサービスも用意する必要もあります。
例えばTerraformやAWS CDKのようにすべての要素を管理できるツールを使えば、インフラの変更もECSのアプリケーションのデプロイも、ひとつのツール（コード）で完結はできます。しかしecspressoは、あえてECS以外の要素を扱いません。これはなぜかというと、実運用におけるライフサイクルが異なることが多いからです。
インフラ的な要素は一度構成されたらそれほど頻繁に変更されません。しかしECS上のアプリケーションは1日に何度もデプロイされて変更されていきます。それぞれを別のチームが管理するという運用もよくあります。そのような場合に両方を一つのツールで扱うと、一方の変更が他のチームにとって意図しない変更を引き起こしてしまう問題が起きがちです。
ecspressoは「操作範囲をECSに限定する」「それ以外の管理はTerraformやCDKなどに任せる（必要な値は参照する便利な機構をつくる）」という設計を採用することで、インフラとアプリケーションという、ライフサイクルが異なるふたつの要素の競合を避けるつくりになっています。
実際にはこのような運用が向く組織と向かない組織、運用手法があると思います。これまで自分がやってきた運用では、システムすべてを一つのツールで管理するのではなく、アプリケーションのデプロイという「隙間」をecspressoで埋める運用が向いていた、ということですね。しかし他の会社でもecspressoが採用されている事例が多くあるということは、そのような隙間はよくあり、そこを埋めるツールが有用であるという証左になるでしょう。
なぜ隙間を埋めるのか
ここからは、「なぜ隙間を埋めるのか」と「なぜそれを社内ツールに閉じず、あえてOSSとしてつくるのか」というお話をしてみます。
まず、なぜ隙間を埋めるのか。理由はシンプルで、現場の困りごとは「隙間」にあるからです。時代が進むほどにメジャーなOSSやフレームワーク、クラウドやマネージドサービスが整ってきます。しかしそれらの大きなものだけだと、最後のひと手間、現場特有の事情、既存資産とのつなぎ込み、チームの習慣のような組み合わせの部分にはどうしても足りないところが出てきます。昔からそのような部分は、グルー（糊）と言われるような、その場その場で作られたコードで補完することがよくありました。
先のECSのデプロイの例でいうと、数個のAPIを順番に呼び出すことで「自作は可能」なのです。デプロイのためにaws-cliやSDKを使って簡易的なスクリプトを内製して運用している、という事例もよくあったように思います。しかしこのようなスクリプトは往々にして他のところにコピペされ、その先で改造され、適切に管理されているとは言い難い状態になりがちです。
OSSにすると、設計は自然と磨かれる
自分はあえてそのような隙間を、OSSとして独立したツールをつくって埋めるということを、いつの間にかやっていました。なぜOSSとしてつくるのか。OSSの価値というと世間に知識を共有するとか、コミュニティができるとか、色々言われることはあります。しかしこれは後から気がついたことなのですが、私が自分でやっていて一番大きいと思う利点は、設計が自然と磨かれることです。
OSSとしてつくる以上、「現場や社内の事情を持ち込むわけにはいかない」という制約が自然にかかります。これは単なる縛りではなくて、設計を洗練させるためにものすごく有効です。
社内ツールでは、どうしても甘えが出ます。たとえば「この部署の運用はこうだから」「既存の◯◯に寄せたいから」といった事情が設計に入り込みやすい。嫌な話ですが圧力もあったりします。「この機能も入れて」「こっちの事情も吸収して」といった要求は、社内では「正当な要求」としてやってきがちです。結果として、どこまでがツールの責任でどこからが使う側の責任なのか、どこまで抽象化してどこを切り捨てるのか。どうしてもそこがブレてしまいます。
OSSでは、そういう要求をそのまま取り込むわけにはいきません。外の人には前提を共有できませんし、社内事情の説明もできません。つくる側は必然的に本質的に使える部分だけを切り出すことになります。一般化できるものだけを取り出し、そうでないものは切り捨てたり、ツールの外で解決しやすい機構を考えることになる。つまり、境界を引く。やらないことを決める。これが、OSSとしてつくること自体に内蔵された強制力です。
私が「隙間家具OSS」を好むのは、この境界設計と相性がいいからです。隙間家具は、サイズを間違えると置けません。やることが増えすぎると隙間に入らない。だから設計段階で、どこに収めるかを決める必要があります。責任範囲を限定して、ちゃんと収まる形にする。結果として、個人でもメンテナンスできるサイズになるし、ユーザーも迷いにくい。境界が切り分けられているなら、将来もし不要になったときにも取り外しやすいのです。
重要なのは、この設計を磨く訓練が「隙間家具OSSに限った話ではない」という点です。設計において重要なのは、境界の切り分けです。プロダクト開発でも、何を内製し、何を外部サービスに任せ、どこをインターフェースとして固定し、どこを変更可能にするか。何を優先し、何を捨てるか。やらないことを決める勇気がないと、プロダクトは肥大して破綻します。隙間家具をOSSとして設計することは、その訓練を日常的にやることになります。
AI時代でも、境界設計は人間の仕事
つい最近の出来事です。2026年2月、Xを見ていたところ「ecspressoライクなAWS Batchのデプロイツール batchaを作ってみた」という記事が流れてきました。
batchaは、ecspressoの設計とエコシステムを流用して、ECSではなくAWS Batchのジョブ定義をデプロイできるツールです。
テンプレートエンジンに kayac/go-config、Terraform state の参照に fujiwara/tfstate-lookup を利用しており、ecspresso と同じエコシステムの上に構築しています。
ecspresso と同様に、変更頻度の高い Job Definition の管理に特化し、ジョブキューやコンピュート環境、ネットワークといった頻繁には変わらないリソースは Terraform などの IaC ツールに任せる設計です。
さらに、実装の多くをClaude Codeが担い、人間は設計の方向づけと調整に徹した、という話も書かれていました。
batcha のコードはほぼ Claude Code が書いたもので、自分は設計の方向付けと調整に徹しました。ecspresso という優れた手本があったのも大きいですが、こういうツールがサクッと作れてしまう、いい時代になりましたね。
ecspressoライクなAWS Batchデプロイツール「batcha」を作ったより引用
この話を見て思ったのは、AIがコードを書ける時代になったからこそ、「境界をどう引くか」がますます重要になる、ということです。設計が言語化できれば、実装はAIに委譲できる。逆に言うと、境界が曖昧なままAIに投げただけでは、要求を飲み込み続ける肥大化した「便利そうな何か」が高速で量産されるだけになるのではないでしょうか。
これから挑戦する人へ、まずは“自分の隙間”を埋めてみる
これからOSSに挑戦したい人に向けて言うとしたら、最初の一歩は小さく始めましょう。プラグインでも、CLIでも、Webアプリでもなんでも構いません。ただし、まず自分が欲しいものをつくるのが良いと思います。自分が使いたい、必要性があるものであればニーズは明確ですし、機能はいくらでも思い付きます。しかしそこで「社内や身内の事情を捨ててOSSとして説明できる形」にすることを考えてみましょう。境界を引く訓練が始まります。
頑張ってOSSとして公開しても、必ずしも誰かの役に立つとは限りません。私がつくったものでも、自分以外にユーザーがいないものもたくさんあります。しかし、実際に自分が必要な要件を満たすソフトウェアを「OSSとして公開するために考える」という行為で得られることは、たくさんあると思います。
そして、もし誰かが使ってくれたなら。batchaのように自分のOSSの設計思想を受け取って新しいものをつくってくれる人が現れたり、blogで使ってみた記事を書いてくれたり。そういう瞬間がOSS活動の中で一番うれしいことのひとつです。自分が欲しくてつくったものが、誰かの現場でも役に立った。そうわかったときの手応えは、コードを書くだけでは得られないものです。
最後に、誰かのOSSを使ってみて、もしそれが良かったら、どんなかたちでも良いので作者にポジティブに伝わるような情報（GitHub Starでも、SNSでの報告でも、blog記事でも）を世の中に出すことを考えてみてください。自分がつくったものが誰かに喜んでもらえる、というのはとても嬉しいことなのです。