1. PoCとは何か
Proof of Concept。「概念実証」と訳される。ある技術やアイデアが実現可能かどうかを、小さく試して確かめる行為。
本来のPoCには明確な構造がある。
- 仮説 — 「この技術でこの問題は解けるか」
- 検証 — 実際に作って試す
- 判定 — できた／できなかった
- 意思決定 — 進む／やめる／方向を変える
この4ステップが回れば、PoCは数日から数週間で終わる。問題はこの4ステップが回らないケースが多すぎることだ。
2. 終わらないPoC
大企業のIT部門でよく見る光景がある。
「PoCをやりました。結果は良好でした。次のステップとして、より大規模なPoCを計画しています。」
これはPoCではない。PoCという名前の永久延期である。
PoCが終わらない組織には共通のパターンがある。
- 判定基準が曖昧 — 何をもって「成功」とするかが事前に定義されていない。だから結果が出ても判定できない
- 失敗を許容しない — 「できなかった」という結論を出すと責任問題になる。だから結論を出さない
- 意思決定者が不在 — PoCの結果を受けて「やる」「やめる」を決められる人間がいない。だから「もう少し検証が必要」と先送りされる
- PoCが目的化している — 「新しい技術を試している」こと自体が実績として報告される。結論は求められていない
PoCの目的は「試すこと」ではない。
「判断すること」である。
3. トキストレージのPoC — Opusの挫折、Codec2の発見
トキストレージの音声QRコードは、一つの明確なPoCから始まった。
仮説：人間の声をQRコード1枚（最大2,953バイト）に収められるか。
PoC 1：Opus
最初に試したのはOpus。Web標準の音声コーデックであり、ブラウザネイティブでデコードできる。理論上、1〜2kbpsまでビットレートを下げれば数十秒の音声がQRに収まるはずだった。
結果は明確だった。Opusは2kbps以下でDTX（不連続送信）に陥り、実質的に無音フレームを出力する。 4kbps以上ではエントロピーが高すぎて圧縮が効かず、QRには2〜3秒しか入らない。2〜4kbpsの間には使える中間地帯が存在しなかった。
判定：Opusでは解けない。
PoC 2：Codec2
次に試したのがCodec2。アマチュア無線向けに設計された超低ビットレート音声コーデックで、450bpsという極端な低ビットレートでも人間の音声を知覚可能な形で保持する。
結果：450bpsモードで約29秒の音声がQRコード1枚に収まった。音質はロボティックだが、誰が話しているかは識別でき、内容は聞き取れる。
判定：Codec2で解ける。
このPoCの全体にかかった時間は数日。仮説があり、検証があり、判定があり、意思決定があった。Opusが「できなかった」という結論を受け入れたからこそ、Codec2に到達できた。
「できなかった」は失敗ではない。
それは次の仮説への入口である。
4. PoCがそのままアーキテクチャになる
トキストレージのPoCには一つの特徴がある。PoCの成果物がそのままプロダクトの一部になったこと。
| PoCの成果 | プロダクトへの反映 |
|---|---|
| Opus不可の判定 | Opusへの依存を設計から排除 |
| Codec2 450bps動作確認 | 6モード（3200/2400/1600/1200/700C/450bps）の実装 |
| QR Version 40で2,953バイト | URL設計の容量制約として固定 |
| WASM上でCodec2が動く | ブラウザ完結アーキテクチャの確定 |
多くの組織で、PoCとプロダクト開発は分断されている。PoCは「技術検証チーム」が行い、その結果を「プロダクトチーム」が受け取り、改めて設計し直す。PoCで得た知見の半分は、この受け渡しの過程で失われる。
トキストレージでは一人がPoCからプロダクトまで一貫して行うため、PoCで得た判断がそのままアーキテクチャの設計原則になる。情報の損失がゼロ。
5. PoCが教える「やめる技術」
PoCの最も重要な機能は、「やめる」判断を可能にすることである。
Opusで音声QRが実現できないと判明した時点で、Opusへの投資を即座に打ち切った。2〜4kbpsの中間地帯を探して最適化を続ける選択肢もあったが、PoCの判定は明確だった。構造的に不可能。
この「やめる」判断ができない組織は多い。すでに投資した時間と予算を正当化するために、「もう少し最適化すれば」「パラメータを調整すれば」と検証を続ける。これがサンクコストの罠であり、終わらないPoCの正体である。
PoCの価値は「できた」にだけあるのではない。「できない」を早期に確定させることにこそ価値がある。
6. PoCの規模は最小であるべき
良いPoCは小さい。仮説一つ、検証一つ、判定一つ。
「音声をQRに入れられるか」は一つの仮説だ。「Opusで入れられるか」は一つの検証だ。「Opusでは無理」は一つの判定だ。そこから「Codec2ならどうか」という次の仮説が生まれる。
大企業のPoCが終わらない理由の一つは、PoCの範囲が大きすぎることにある。「AIを業務に活用できるか」は仮説ではなく願望だ。「この帳票のこの項目をGPT-4で分類できるか」が仮説である。
仮説が小さいほど、検証は速く、判定は明確で、意思決定は容易になる。
7. 結論 — PoCは判断の道具である
PoCは「試す」ためではなく「決める」ためにある。
検証の結果を受け入れる覚悟がなければ、
PoCは永遠に終わらない。
トキストレージの音声QRコードは、Opusの挫折から始まった。「できなかった」を受け入れたからCodec2に到達し、Codec2が動いたからアーキテクチャが確定し、アーキテクチャが確定したから今日まで構造が揺れていない。
PoCとは技術のデモンストレーションではない。意思決定の道具である。判定基準を事前に定め、結果を受け入れ、次に進む。その繰り返しが、ハリボテではない構造を生む。
問いはいつも同じだ。PoCの結果を、受け入れる準備はあるか。