先に要点
- 自作フレームワークの9 割は地雷。理由は 「保守コスト・採用難・ドキュメント不足・テストカバレッジ不足」 が複合的に効いて、5 年後に「誰も触れない遺産」 になりやすいから。
- それでも自作が正解になるケースはある。(1) 業務ドメインが特殊で既存フレームワークに乗らない、(2) 学習目的(教育 / 採用ブランディング)、(3) 既存フレームワークでは性能要件が満たせない、(4) 内製プラットフォーム企業の戦略商品として作る ── この 4 パターン。
- 大半のケースで 「既存フレームワーク + 薄い社内ラッパー / 規約集」 が最適解。「フレームワークを作る」 のではなく「既存フレームワーク の上に薄い社内標準を載せる」 だけで、自作のメリットの大半を取れる。
- AI 時代になって、「自作する側」 の初期コストは下がったが、保守コストの「人類社会との接続性」 部分は変わらない。AI が自社フレームを学習データで知らないと、AI 補助が効かない問題が新たに発生する。
「うちの業務に既存フレームワークが合わない、いっそ自社で作ろう」「ライブラリを組み合わせてラッパー書いてるうちに、ほぼフレームワークになってきた」「採用面接で『社内フレームワーク開発経験』 と書いてある人をどう評価する?」 ── 自作フレームワーク(社内フレームワーク)は、エンジニアの自尊心とコスト感覚と組織戦略が交錯する、判断が難しい領域です。
ざっくり言うと、「やめておけ」 が大半の場面での正解です。ただし、4 つほど明確に「作って良い場面」 があります。本記事ではメリット / デメリットを整理した上で、その判断軸を提示します。
自作フレームワークとは何を指すか
最初に定義を整理します。「自作フレームワーク」 と一口に言っても、レベルがいくつかあります。
レベル 1: 単なるユーティリティ集
共通関数 / クラスを lib/ や utils/ に集めた程度のもの。これは「フレームワーク」 とは呼ばない。社内ライブラリ。
レベル 2: 既存フレームワークの社内ラッパー
Laravel や Spring Boot の上に社内規約や共通処理を被せたもの。「フレームワーク的」 だが、本体は既存フレームワーク。実体は「設定 + 規約集 + ヘルパー」。後述する中間解はここ。
レベル 3: ゼロから書いたフレームワーク
ルーティング / コントローラ / DI / ORM / テンプレートエンジンなどを独自に実装した、本物の自作フレームワーク。「うちは自社フレームワークがあります」 と聞いたら大体これ。本記事の主な議論対象。
レベル 4: 言語ごと作る(DSL)
業務ドメイン専用の独自言語 / DSLを作るレベル。金融や保険、製造の専用システムで稀にある。本格的なソフトウェア工学プロジェクト。
レベル 2 と 3 の境目を見誤って、「気付いたらレベル 3 になっていた」 パターンが現場で最も多い失敗です。
なぜ作りたくなるのか
そもそも、なぜ人は自作フレームワークを作りたくなるのでしょうか。動機を分解すると、メリット / デメリットの判断材料になります。
既存フレームワークの不満
「重い」「自由度が低い」「うちの業務に合わない」「無駄な機能が多い」 という機能的な不満から。エンジニアとしては自然な発想だが、不満の解決策が「自作」 とは限らない。
学習意欲 / 知的好奇心
「ルーティングってどう実装するんだろう」「DI コンテナを自分で書きたい」 という純粋な技術的興味。これ自体は良いことだが、業務システムに持ち込むかは別問題。
NIH 症候群(Not Invented Here)
「他人の作ったものは信用できない」「うちで作った方が分かる」 という心理的バイアス。組織が古い / 閉鎖的なほど起きやすい。客観的な根拠がないなら、これが疑われる。
「不満の解決」「学習」「NIH」「ブランディング」 のどれかが動機。「NIH」 が動機の自作はほぼ 100% 後悔すると覚えておくと判断が早くなります。
メリット — 自作が生む価値
自作フレームワークの本物のメリットを整理します。
| メリット | 具体例 | どれくらい本物か |
|---|---|---|
| 完全な制御 | 機能の追加 / 削除を自由に行える、依存関係が無い | 本物。だが代償が大きい |
| ドメインへの最適化 | 業務固有のパターンを言語化、繰り返し処理を激しく短縮 | 本物。ただし業務が特殊な場合のみ |
| 学習効果 | フレームワークの仕組みを理解、メンバーの設計力が上がる | 本物。個人 / 副業 / OSS なら最大化される |
| 採用ブランディング | 「自社フレームワークがある会社」 として注目される | 会社規模で本物だが、組織の体力次第 |
| ベンダーロックイン回避 | OSS フレームワークの開発停止リスクを避けられる | 幻想に近い。自作は自社へのロックインに置き換えただけ |
| パフォーマンス | 不要な機能を削って軽くできる | 本物だが、効くのは超大規模システムだけ |
| セキュリティ統制 | 業界規制(金融 / 医療)の固有要件を組み込みやすい | 本物。ただし通常は既存フレームワーク + 監査ログで足りる |
メリットは確かに存在しますが、「自社の業務が本当に特殊か」「組織にそれを支える体力があるか」 を厳しく問わないと、「自尊心の充足」 で止まります。
デメリット — 自作が壊すもの
デメリットの方が、ほとんどの組織にとっては圧倒的に重いです。
保守コストが永遠に乗る
OSS フレームワークなら世界中のコミュニティがバグ修正・セキュリティパッチ・新機能追加を担う。自作はそれを全部自社負担。10 年保守するなら、10 年分の専任エンジニアコスト(人件費 1〜数億)が乗る。
採用が難しくなる
「Laravel 5 年経験」 ならエンジニア市場に大量にいるが、「自社の独自 XYZ Framework 5 年経験」 は社外に 0 人。新人 / 中途を採っても、最初の数ヶ月は自社研修に時間を取られる。
ドキュメントが永遠に追いつかない
OSS なら公式ドキュメント + Stack Overflow + ブログ記事 + 書籍が無料で揃う。自作は社内 Wiki に書くしかない。書く人がいない、書いても古くなる、結局口伝になる、というのが定番の崩壊パターン。
エコシステムが無い
OSS ならテストツール / モニタリング / IDE 補完 / 拡張ライブラリが揃う。自作はゼロから整える必要があり、結局「既存 OSS のラッパーを書く」 ことに無限の時間を使う。
セキュリティ問題が見つからない
OSS は世界中の研究者が脆弱性を探し、すぐパッチが出る。自作の脆弱性は誰も探していないので、攻撃を受けるまで気付かない。OWASP Top 10 対策のような「業界の標準」 も自分で実装し直す必要がある。
作った人が辞めた瞬間に詰む
自作フレームワークの設計思想を理解している人が 1〜2 人だけ、というのが普通。その人が退職すると、新しい機能追加 / トラブル対応が一気に止まる。「神様エンジニアの私物化リスク」。
AI 補助が効かない
2026 年の AI コーディング環境(Claude、Cursor、GitHub Copilot)は、Laravel や Spring の知識は豊富だが、自社の独自フレームワークは知らない。学習データに無いので、補完精度が落ち、生産性向上の恩恵を受けにくい。これは新しいデメリット。
「成功体験」 への愛着
自作が機能していると、「これがあるから今がある」 という感情的なバイアスが組織に染み付く。本来は捨てるべき場面でも捨てられず、ますます身動きが取れなくなる。
「保守コスト + 採用難 + AI 補助の弱さ」 の 3 つは、特に 2026 年現在は致命的です。
自作が正解になるケース
それでも自作が合理的なケースは、明確に存在します。
業務ドメインが本当に特殊
金融の板寄せエンジン、保険の料率計算エンジン、製造の制御 PLC 連携、医療の画像処理パイプラインなど、汎用フレームワークの想定外な領域。ここは自作が必然になる場面もある。
プラットフォーム企業の戦略商品
自社フレームワーク自体を収益商品として提供する場合(Salesforce、kintone、Backlog SDK など)。これは「自作」 ではなく「製品開発」 で、コスト構造が全く違う。
「特殊ドメイン」「製品としての戦略」「物理的な性能要件」「学習目的」 のどれにも当てはまらないなら、自作はやめておくのが安全です。
自作が地雷になるケース(よくある誤判断)
逆に「やってはいけない自作」 のパターン。
| 動機 | なぜ地雷か |
|---|---|
| 「Laravel が遅いから自作する」 | 9 割は Laravel の最適化で解決する。本当の性能限界に達してから検討 |
| 「Symfony は重いから軽量フレームを自作」 | 軽量化を求めるなら既存の軽量 OSS(Slim / Mojolicious / Echo / Fiber)を採用 |
| 「うちの業務に合うフレームがない」 | 大半は合わないと思い込んでいるだけ。既存 + 設定 + 規約集で十分 |
| 「ベンダーロックインが嫌」 | 自作は自社へのロックインに置き換えただけ。さらに脱出困難 |
| 「セキュリティのために独自実装」 | 独自暗号 / 独自認証はほぼ確実に既存より弱い。「Don't roll your own crypto」 の格言 |
| 「採用ブランディングで」 | 有名 OSS にコントリビュートする方が、ブランディング効果は安く高い |
| 「面白そうだから」 | 業務時間に持ち込まず、個人プロジェクトでやる |
「動機が NIH / 自尊心 / 学習意欲」 だけなら、業務に持ち込まないのが組織の利益です。
中間解 — 既存フレームワーク + 薄いラッパー
自作のメリットの大半は、「既存フレームワーク + 社内ラッパー / 規約集 / 共通ライブラリ」 で取れます。
「既存 + 薄い社内基盤」 は、自作のメリットを 9 割取って、デメリットを 1 割に抑える 黄金パターンです。
AI 時代の自作フレームワーク
2026 年の AI コーディング環境の普及で、自作フレームワークの判断軸が変わりました。
作る側のコストは下がった
AI がルーティング / DI / ORM のボイラープレートを書いてくれるので、「ゼロから書く工数」 は数分の 1 に。「3 ヶ月で社内フレームを作る」 が物理的に可能になってきた。
保守の AI 恩恵は受けられない
AI はOSS のフレームワーク(Laravel / Rails / Spring 等)は学習データで深く知っているが、自社の独自フレームは知らない。コード補完・バグ修正提案の精度が露骨に落ちる。「AI 時代に自作するなら、AI 抜きで保守する覚悟」 が必要。
採用面接での評価が変わった
「自社フレームワーク 5 年」 という経験は、AI 補助が効かない時代に市場価値の見極めが難しいスキル。OSS フレームワーク経験 + AI 活用力のほうが、転職市場では強い時代に入っている。
逆説的に「AI 時代だから自作」 もあり得る
AI で生産性が爆上がりした結果、「うちのドメインに最適化した DSL を AI に喋らせる」 ような戦略で自作する意義は新たに生まれている。ただしこれは「フレームワーク開発 + AI プロンプト設計 + 社内教育」 をワンセットでやる前提。
「作るコストは下がった、保守と AI 補助のコストは上がった」 という新しい力学。「AI に教えやすい標準的な OSS を採用する」 が、ますます理にかなった選択になっています。
自作フレームワークに関するよくある質問
Q. 一言でまとめると、自作フレームワークは作るべきですか?
A. 99% のケースで作らない方が良いです。例外は、(1) 業務ドメインが本当に特殊、(2) 自社製品として売る、(3) 物理的に既存では性能要件が満たせない、(4) 学習目的の個人プロジェクト ── のいずれか。「Laravel が遅い / 不満」 のような曖昧な理由は該当しません。
Q. 既存フレームワークが業務に合わない、と感じる場合は?
A. 「本当に合わないのか」 を疑ってください。多くの場合、合わせる側のスキル不足 / 設計不足が原因です。Laravel / Rails / Spring などの定番フレームは何百万件のシステムで運用されており、「あなたの業務だけ合わない」 はまず無い。それでも合わないなら、「既存 + 薄いラッパー」 で 9 割解決します。
Q. 自作フレームワークのある会社に転職する場合、評価ポイントは?
A. (1) なぜ自作したのか(明確な技術的理由があるか、NIH ではないか)、(2) ドキュメントが整っているか(無いと地獄)、(3) AI コーディング環境がどれだけ使えるか(自社フレームは AI が知らない問題)、(4) 設計者が現役か(辞めていると教えてくれる人がいない)、(5) OSS への切り戻しが議論されているか(健全な組織は将来の選択肢を残す)。これらを面接で確認すると、地雷案件かが見える。
Q. 自社フレームワーク経験は転職市場で価値がありますか?
A. 残念ながら、近年は価値が下がっています。受け手の会社からすると、「Laravel 経験」「Spring 経験」 のほうが即戦力として読みやすい。「自社フレームワーク 5 年」 だけだと、面接官は「ベース技術の理解度」 を疑います。対策は、社内フレームワークのベースになっている OSS フレームワーク(例: 「これは Symfony の上に被せていた」)を明示的に書き、両方の経験として表現することです。
Q. 個人開発で自作フレームワークを作るのは?
A. 大いに推奨します。フレームワークの仕組みを理解することは、エンジニアとして大きな学習。「自分でルーティング / DI / ORM を書いてみる」 と、OSS フレームワークを使うときの解像度が劇的に上がります。業務に持ち込まず、個人プロジェクト / 副業 / OSS として続けるのが、リターン最大化の道。
Q. 「既存フレームワーク + 薄いラッパー」 の境界はどこで引くべきですか?
A. 「素の OSS フレームワークに戻せるか」 が基準です。社内ライブラリ / スカフォールド / 規約集レベルなら、いつでも剥がせる。ところが独自のルーティング DSL / 独自の ORM / 独自のテンプレートエンジンを作り始めた時点で、剥がせなくなり、本物の自作フレームワークへ滑り落ちます。「剥がせる状態を保つ」 が中間解の生命線。
Q. AI 時代に自作フレームワークの価値はどう変わりましたか?
A. 作るコストは下がり、保守の AI 補助は受けられない、というアンバランスが生まれました。AI が Laravel や Rails のコードを補完する精度は非常に高い一方、自社の独自フレームワークは AI が知らないので補完精度が落ちる。これが新しいデメリットです。逆に、業務ドメインに特化した DSL を AI に喋らせる 戦略を取るなら、自作の意義は生まれる可能性もあります。いずれにしろ、「OSS を採用する戦略のほうが AI 補助を最大化できる」 構図が強くなっています。
参考リンク
- Joel Spolsky: Don't Let Architecture Astronauts Scare You
- Martin Fowler: Inversion of Control Containers and the Dependency Injection pattern
- Wikipedia: Not invented here
- 関連記事: 代表的なフレームワークとユースケース / 枯れた技術を選ぶ価値 / 既存システムのフレームワーク特定方法 / AI でレガシー保守を加速する