01最大の教訓：順序が逆だった
先に、いちばん高くついた失敗を書きます。評価の順序が逆でした。
私たちが実際にやっていた順序 と、直した順序
従来（約85回これをやった）
① ライセンスを確認する
② §0 セキュリティ監査をする
③ 作れるか技術検討する
④ 最後に需要を見る → 不在で落とす
確定版
① まず需要を見る（第0段・5〜10分）
② ここで大半が落ちる
③ 残ったものだけライセンス・§0
④ 作れるかは最後でいい
ライセンスと§0は数時間かかります。需要チェックは数分です。安い判定を先にやるだけで、無駄な深掘りが激減しました。
当たり前に見えますが、実際にはやってしまいます。理由は、ライセンスやセキュリティは「調べれば答えが出る」から気持ちがいいのに対し、需要は「無い」を証明しにくく、判定が気持ち悪いからです。気持ちのいい作業を先にやって、気持ち悪い作業を後回しにしていました。
02第0段：5〜10分で大半が落ちる
需要側の3チェックです。合わせて5〜10分。ここを通らないものは、その先を調べる意味がありません。
第0段の3チェック
- 上流が公式マネージド／有料SaaSを提供しているか提供済みなら即アウト。「本家がやっていない日本語マネージドを我々が」という前提が崩れ、価格の説明もできなくなる。
- Qiita / Zenn に日本語の技術記事が実在するかAPIで記事数を数える（同名の別物を除去すること）。Zenn 0件かつQiita 1桁なら需要不在を疑う。複数の著者が書いた実記事が無ければ、日本で誰も運用していない。
- 日本語への翻訳率ロケールファイルを直接ダウンロードして実測する。高すぎても低すぎても失格シグナル（次章）。
この3つを最初に当てていれば、いくつもの候補を数分〜30秒で落とせていました。日本語記事数の正しい測り方は別記事にまとめています（全文検索は英単語衝突で使えず、Qiitaタグの記事数が有効でした）。
03翻訳率は、両方向から罠になる
私たちの当初の中核仮説は「日本語化されていない＝チャンス」でした。これが両方向から壊れました。これは自分たちの前提が崩れた、いちばん大きな発見です。
翻訳率の読み方（私たちが実測して気づいたこと）
翻訳率が高い
差別化の余地がない。しかも誰かが既に翻訳に投資している証拠。そこは埋まっている
翻訳率が極端に低い
日本人が誰も使っていない証拠であることが多い。ロケールに日本語だけ無い＝需要が無かった
「低いからチャンス」でも「高いから安心」でもない。翻訳率だけでは、良い悪いの向きすら決まりません。
翻訳は堀にならない
さらに、WeblateやCrowdinのような公開型の翻訳基盤は、誰でも翻訳を投入できます。私たちが日本語化しても、同じことを誰でもできる。翻訳そのものは、防御可能な堀にはなりませんでした。（※匿名ユーザーは提案のみ、というプロジェクトもあり、そこは別記事で厳密に扱っています。）
1つだけ、区別が要る
「そのOSSに日本人ユーザーがいない」と「その業務領域に日本の需要が無い」は別物です。日本固有の規制で生まれた需要（例：白ナンバーのアルコールチェック義務）は、海外OSSに日本人ユーザーがいなくて当然。この場合の需要は市場側（既存の有料プレイヤーが売れているか＋法規制）で判定します。ただしその道は「日本でカテゴリをゼロから作る」ことになり、集客の壁に直撃します——これは私たち自身が身をもって確かめました。
04第1段：市場と参入障壁の11チェック
第0段を通ったものだけ、市場を詳しく見ます。ここで繰り返し効いたのが、「高すぎる価格帯が空いている」という期待が、毎回事実で否定されたことでした。空いて見える上の価格帯には、たいてい理由がありました。
第1段：参入障壁の11チェック
1-1 既存プレイヤー
国内の競合を具体名＋価格で列挙する。「高い層が空いている」という期待はほぼ毎回否定された
1-2 無料の巨人
無料または大手にバンドルされた選択肢がないか（表計算・各種フォーム・OS/オフィス同梱のツールなど）
1-3 国産OSS＋公式クラウド
日本ではこの組み合わせが定着している領域がある
1-4 隣接収益
本体を無料にして別の売上（印刷・決済手数料等）で回収する競合がいると、構造的に価格で勝てない
1-5 規制の罠
①認証が購買条件 ②規制予算が認証製品に吸われる。別記事で詳述
1-6 公的機関の無償提供
国や公的機関が無料で提供している領域は、そこから顧客が吸い上げられている最中のことがある
1-7 日本固有データ形式
法定帳票・業界標準フォーマットなど、翻訳では埋まらない壁がないか
1-8 買い手は非エンジニアか
エンジニアが買い手＝自前で建てられる＝マネージドが売れない
1-9 粗利率フィルタ
その領域の国内上場企業の粗利率が低いなら、データ量従量などのコスト構造を疑う
1-10 ハード同梱
顧客に機材購入を求める領域（カメラ・車載器等）は、ソフト単体では戦えない
1-11 法改正追随コスト
労務・会計・税務は法改正のたびに保守義務が発生し、個人には過大
05第2段・第3段：ライセンスとセキュリティ
ここまで生き残ったものだけ、ライセンスとセキュリティを詳しく見ます。この2段は、他の記事で1本ずつ深掘りしているので、ここでは要点だけ。
第2段（ライセンス）と第3段（§0 セキュリティ）
- LICENSE本文を実取得するSPDX表示・GitHub API・READMEを信用しない。本文を読むまで用途制限は分からない（実例集）。依存に再販禁止の専有バイナリが紛れていないかも見る
- 任意コード実行が機能の中核でないか数式・SQL・スクリプトを実行させる製品は、認可の境界が製品全体に薄く広がり、テナント分離が構造的に難しい
- フォークは祖先＋兄弟のCVEを合算する製品名だけで脆弱性を検索すると、改名前・フォーク元の重大CVEを見落とす
- 認可層が繰り返し壊れていないか権限昇格や他人のデータが見える不具合が反復して出る製品は、テナント境界に使えない
セキュリティは私たちの最優先ルール（顧客データを預かる以上、脆弱な土台は不可）です。1つでも解消不能な重大リスクがあれば、そこで即除外します。
06結局、成立する条件は1つだけだった
約85候補を落とし切った末に残った、私たちのモデルが成立する条件は、たった1文でした。
成立条件
日本で既に自前運用している人がいて、その運用に苦しんでいて、しかも国産のマネージドが無い、OSS。
つまり「製品名 構築」「製品名 日本語」で既に検索している人が実在すること。流入が既にある所にしか、入れませんでした。
つまり「製品名 構築」「製品名 日本語」で既に検索している人が実在すること。流入が既にある所にしか、入れませんでした。
日本語記事の量で、両側から挟まれる
記事ゼロ
需要をゼロから創る
→ 流入が作れず死ぬ
→ 流入が作れず死ぬ
ちょうど中間
ここだけが的
運用者はいるが国産管理は空席
運用者はいるが国産管理は空席
記事が厚い
既に国産SaaS/マネージドが
埋めている
埋めている
この極めて狭い交差点が、私たちの実際の的でした。狭すぎて、稼働中の候補4本はいずれもここを外していた、というのが正直な結論です。
07カテゴリごと撤退を決めた領域
個別のOSSではなく、領域まるごと「ここは狙わない」と決めたものがあります。私たちの調査の範囲での判断ですが、同じ轍を踏む人のために残します。
撤退を決めた領域と、その理由
| 領域 | 撤退理由（私たちの調査範囲での判断） |
|---|---|
| POS・レジ | 大手が本体無料・決済手数料で回収。決済ライセンスなしでは構造的に不可能 |
| グループウェア | 大手オフィススイートにバンドルされ、機能が真部分集合になりやすい |
| 業務データベース | 国産の低価格製品が定着。その下は無料の表計算 |
| EC | 国産OSSの日本固有エコシステム（決済・法対応・配送連携・制作会社の厚み）を海外OSSは持たない |
| 文書管理・電帳法 | 国産低価格＋無料の認証済みサービス（別記事） |
| 労務・会計・税務 | 法改正追随コストが個人に過大（法規の壁とも接続） |
| 医療 | OSSのAGPL採用率が構造的に高く、掘る費用対効果が悪い |
| 介護・保育・美容・葬儀・整備・士業 | 実用品質のOSSが事実上存在しない（＝制度依存が重すぎるか、開発者との接点が無い業種） |
「空白市場」に見えても、多くは「需要がない」か「構造的に埋められない」のどちらかでした。空白と機会は違います。
この手順の使いどころ
これは「オープンソースを日本語マネージドSaaSにして個人・少人数で売る」という特定のモデルのための足切りです。大企業がやる場合や、別のマネタイズ（サポート受託・導入支援）なら、通るゲートは変わります。私たちのモデルでほぼ全滅した、という事実そのものが、いちばんの一次データです。
この手順は、私たちがオープンソースを日本語のマネージドサービスとして提供する（Miqto）ために約85候補を評価する中で作りました。あわせて読む：日本でOSSマネージドが成立した事業者を全部調べた／日本人が実際に使っているOSSを実測した／「規制があるから需要がある」は罠になりうる／Redmineが日本で強い理由と、その市場構造／OSS ERPは日本で使えるのか／国産「社内AI」SaaSの価格と中身を全部調べた／「オープンソース」に見えて商用利用できないOSSカタログ／OSS候補の探し方を間違えていた話。
データ・出典
- 本記事の一次データは、私たち自身が約85個のオープンソースを同一の基準で評価した記録です。母集団のライセンス機械判定（1,332件）はセルフホストOSS 1,332件のライセンスを全数調査した、日本語記事数の実測は日本人が実際に使っているOSSを実測したに、それぞれ再現方法つきで公開しています。
- 第0段の「日本語記事数」の測り方（全文検索が使えず、Qiitaタグの記事数が有効だった経緯）：同上
- 翻訳率の測定（Weblate REST API で公開プロジェクトの ja 翻訳率を取得する方法）と「翻訳は堀にならない」の厳密な検証：「日本語化すれば売れる」は本当か
- 規制系の「認証ゲート」の詳細：「規制があるから需要がある」は罠になりうる
本記事は、特定のオープンソースや事業者を評価・推奨・非推奨するものではありません。記載した領域ごとの判断は、あくまで「オープンソースを日本語マネージドSaaSにして個人・少人数で売る」という私たち自身のモデルにおける、確認できた範囲での相対評価です。別のビジネスモデルや体制では結論が変わります。競合製品の価格・仕様・無料範囲は変更され得ます。特定の製品名を避けて一般化して記述している箇所は、個別企業の評価を避けるためです。