Zero-Input Project Observatory

意思決定は、
報告を待てない。

動いているプロジェクトの“いま”が、ひとりでに見える。
既存の業務システムが日々こぼすシグナルを集め、
プロジェクトという白色光を、判断できる粒度へ分光する。

経営層ビューを見る思想を読む

観測対象: 27案件
要判断: 3件
売上見込み確度: 87%
現場の入力工数: 0分／日

08:00 PRISM

経営層ビュー

2026.07.30 08:00 自動観測／訂正 0 件

27 全案件

赤信号

3件

順調

24件

来月の売上見込み確度 87 %

閾値 80 % ／下回れば要確認として通知

案件A・設計フェーズ遅延 3 日
案件D・仕様確定待ち停滞 5.4 日
案件K・見積再作成2 回目

赤信号 3 件のうち 2 件は同一人物のリソース超過が原因。
この画面は、誰も更新していない。

The Blind Spot

知りたいのに、知れない。

経営が把握できていないのは、案件の存在ではない。案件の“温度”である。どれが危ういのか、なぜ危ういのか、いつ手を打てば間に合うのか。その三つが揃って初めて判断になるが、揃うのはたいてい、手遅れになってからだ。

月次で上がってくる数字は、すでに起きたことの記録である。
経営が必要としているのは、まだ起きていないことの兆しだ。

— 20〜200名規模の技術系企業に共通する構造的な盲点

27件

同時に走るプロジェクト。開発・受託・実証実験・保守が性質を異にしたまま並走する。

3件

いま赤信号にある案件。ただし信号の色だけでは、何を決めるべきかは分からない。

2件

その赤信号のうち、原因が同一人物のリソース超過に帰着するもの。人を1人動かせば2件が戻る。

0.91

受注からキックオフまでの属人化スコア。特定の1名が抜ければ、そこで全部が止まる。

導入直後: 全員が律儀にステータスを入力する。数字は美しく揃う。

1ヶ月後: 最も忙しい人から更新が遅れ始める。つまり、最も重要な案件から欠ける。

3ヶ月後: 更新は週次になる。会議の直前に、記憶を頼りに埋められる。

6ヶ月後: 誰も見ない。次のツールの選定が始まる。同じことが繰り返される。

Jira も Backlog も Notion も、優れたツールである。
壊れているのはツールではなく、「人間が正しく入力し続ける」という前提のほうだ。
その前提を置いたままでは、経営が受け取る数字は常に一段古い。

Zero-Input

報告を待つ経営から、
観測する経営へ。

エンジニアも現場も、すでに大量の進捗シグナルを発している。コミット、レビュー、打合せの実績、議事録の更新、見積の改訂、点検完了の一報。すべて“すでに存在する”。ただ、散在していて、判断できる形になっていないだけだ。
PRISM はそれを集め、解釈し、状態を推定する。人が担うのは入力ではなく、 推定が違っていたときの訂正だけになる。

6系統のシグナル束

解釈と推定

進捗

リソース

知識

リスク

壱 — 収集

繋ぐだけ。
入力欄は、ひとつも増えない。

GitHub、Slack、カレンダー、Drive、見積・受発注、現場報告。既存システムを認証で繋いだ時点で観測が始まる。業務の書式も運用ルールも変えない。全部が繋がらなくても、繋がった分だけ精度が出る。

初期設定 約30分 ／現場の追加作業 0

弐 — 分光

状態を推定し、
確からしさを併記する。

非構造のログから案件の状態を推定する。断定はしない。すべての推定に確信度を付け、閾値を下回るものは“要確認”として人に返す。訂正はそのまま学習データになり、使うほど推定は締まっていく。

確信度の閾値 0.80 ／訂正はワンタップ

参 — 翻訳

同じ実態を、
三つの粒度で言い換える。

経営層には数字と信号と選択肢。PM にはボトルネックと打ち手。開発者には今日の一手だけ。上の階層のために、下の階層に作業を発生させない。この一点を守れないなら、このプロダクトは既存ツールと同じ末路をたどる。

下向きの依頼 0 ／集約は常に上方向

既存ツールは「人間に入力させて、見せる」。
PRISM は「勝手に集めて、役割別に翻訳して、自動化まで持っていく」。

Three Instruments

観測機器は、三つの機構で成る。

見える化で終わらせない。可視化は目的ではなく、自動化に至るための前工程である。

01ZERO-INPUT

Zero-Input 進捗推定

人が更新しなくても、進捗は動いている。PRISM は既存システムのログから案件の状態・遅延・停滞理由を推定し、確信度とともに提示する。報告のための会議も、会議のための資料作成も、判断の前提から外れる。

コミット・PR・レビューの往復から、実装フェーズの進捗を推定する
「詰まってます」「終わりました」の一言を、状態遷移として解釈する
推定が外れたら訂正するだけ。訂正の回数そのものが精度指標になる
APIで取れない現場作業は、チャットへの一言報告を受け口にする

観測サマリ

連携系統: 6種
推定確信度（平均）: 0.87
要確認として返す率: 11%
現場の入力工数: 0分／日

02TRANSLATION

3階層自動翻訳ビュー

経営層・PM・開発者は、同じ事実を違う粒度で必要としている。 PRISM は一つの観測結果を三つの語彙へ自動的に翻訳する。経営が見る画面は、現場が何も追加作業をしなくても埋まっている。

経営層：全案件の信号、原因の帰着先、来月の売上見込み確度
PM：フェーズ別の遅延日数、待ちの発生源、掛け持ちによる稼働率
開発者：今日やるべき3つ。うち誰の待ちを解くものかを明示
信号の色で止まらず、原因の階層まで下りられる

階層と集約の向き

経営層27案件／赤3件／確度 87 %

PM設計3日遅延／稼働 132 %

開発者今日の一手 3件／報告不要

集約は常に上方向のみ。下向きの報告依頼は発生しない。

03PROCESS MINING

プロセスマイニングと自動化提案

蓄積された実作業ログから、誰も書いていないが実在するプロセスを再構成する。どこで滞留し、どこが特定個人に依存し、どこが何度もやり直されているか。見えた歪みに対して、PRISM は自動化の候補を金額と頻度つきで提案する。

「見積修正の40%は現場条件の相違が原因」— 事前チェックの設計へ繋ぐ
「この承認、過去120件すべて承認」— 閾値以下の自動承認を提案する
「この報告書、月8回、同一書式」— 自動生成の対象として起票する
属人化スコアで、抜けたら止まる案件を先に数える

検出された改善余地

実施フェーズ平均滞留: 9.8日
見積修正が2回発生: 40%
キックオフで停滞: 25%
属人化スコア（最大）: 0.91

※ 数値は想定運用時のイメージ値です。実データでの精度検証は導入前の検証フェーズで実施します。

Pricing

導入負荷を、価格でも裏切らない。

「繋ぐだけで使える」を売りにしている以上、高額な導入コンサル費は価値提案と矛盾する。
初期費用は最小に。人数課金でシンプルに。
自動化が進むほど、双方の利益が同じ方向を向く。

Starter

〜20名／まず1部門で観測を始める

800 円／人・月

3階層自動翻訳ビュー
基本連携 3種（GitHub / Slack / カレンダー）
Zero-Input 進捗推定・確信度表示
ポートフォリオ横断ダッシュボード

この構成で相談する

推奨

Standard

〜100名／全社の案件を一枚に載せる

1,500 円／人・月

Starter の全機能
全連携（Drive / 見積・受発注 / 現場報告ほか）
属人化分析・バス係数の算出
予兆検知アラート（遅延・稼働超過）
リソース競合検出と平準化提案

この構成で相談する

Enterprise

100名〜／統制と自動化まで一体で

個別見積

Standard の全機能
プロセスマイニング・自動化候補スコアリング
自動化エージェント基盤
SSO / 監査ログ / 権限設計
オンプレミス・専用環境での提供

要件を持ち込む

Automation Add-on従量課金

全プランに追加可能。自動化ワークフローの実行数に応じた課金です。お客様の業務が減るほど当社の売上が増える構造にしてあります。自動化の価値が出ていない月に、費用だけが立つことはありません。

想定 ARPA: 90万円／年
想定 CAC: 60万円
LTV / CAC: 5.6

Voices

判断の速度が、静かに変わる。

赤信号が3件ある、という情報には価値がない。3件のうち2件が同じ人のリソース超過に帰着する、という情報には価値がある。人を1人動かす判断が、月次会議を待たずにその日に下せるようになった

代表取締役 ドローン計測・受託開発／従業員68名
PRISM 導入 7ヶ月

以前は、案件が危ないと分かるのが遅延の発生後だった。いまは仕様確定待ちの停滞が5日を超えた時点で上がってくる。まだ打ち手が残っている段階で知れるかどうかで、機会損失の額が一桁変わる

取締役 CTO 産業機器メーカー／従業員142名
PRISM 導入 11ヶ月

正直、また形骸化すると思っていた。入力を求められないので形骸化する余地がない、というのが答えだった。導入3ヶ月目に、私が作っていた週次の集計資料がそのまま不要になった

PMO マネージャー システムインテグレーター／従業員95名
PRISM 導入 5ヶ月

※ 掲載しているコメント・企業属性はデモ用のイメージです。実在する導入企業の発言ではありません。

Questions

先に、疑っておくべきこと。

ありません。PRISM は置き換えを求めません。 既存ツールの上に乗る観測レイヤーとして設計しています。Jira や Backlog はこれまで通り運用したまま、 PRISM がそこからデータを読みます。移行計画も、データ移送も、運用ルールの再設計も不要です。

これは妥協ではなく設計判断です。乗り換えを要求した瞬間に導入判断のハードルは跳ね上がり、「入力させない」という主張と矛盾します。既存ツールが形骸化していても構いません。人が入力しなくなった後に残るログのほうを、PRISM は読みます。

個人の生産性を評価する指標を、意図的に実装していません。 コミット数の個人ランキング、稼働時間の個人比較、作業量スコア — これらは機能として存在しません。仕様上、作れないようにしています。

PRISM が見せるのは「作業量」ではなく「詰まり」と「待ち」です。誰が遅いかではなく、どこで止まっているかを見ます。また導入時には「何を見て、何を見ないか」を明文化して全員に開示することを標準の手順にしています。開発者ビューの第一の価値は、上への報告作業が消えることに置いています。

外れる前提で設計しています。すべての推定に確信度を併記します。 閾値（初期値 0.80）を下回る推定は断定せず、「要確認」として人に返します。推定を装った断定はしません。訂正はワンタップで、そのまま学習データになります。

これは当社が認識している最大のリスクでもあります。だからこそ導入前の検証フェーズで、御社の実データによる精度検証を最優先で行います。精度が実用に耐えないと判断された場合は、まず「推定」ではなく「シグナルの集約表示」から始める段階導入も選べます。

Enterprise プランで対応します。 オンプレミス設置および専用環境での提供、SSO、監査ログ、権限設計を含みます。防衛・インフラ・医療など、外部送信の制約が厳しい領域での運用を想定した構成です。

推定エンジンの一部を閉域内で動かす構成も取れます。ネットワーク要件・保管期間・ログの取り扱い範囲は個別に設計しますので、情報システム部門と直接お話しさせてください。

接続は約30分。観測結果が意思決定に足る密度になるのは、おおむね2〜4週間です。 初期設定は既存システムの認証だけで、業務フローの棚卸しも要件定義も不要です。過去ログを遡って読むため、初日から一定の可視化は立ち上がります。

属人化スコアやプロセスの再構成は、ログの蓄積量に精度が依存します。おおよそ3ヶ月分の実作業ログが揃った段階で、自動化候補の提案が実用的な粒度になります。導入支援費は最小に抑えています。高額なコンサル費を取ることは、価値提案と矛盾するためです。

全部が繋がらなくても、繋がった分だけ価値が出る設計です。 現場作業や Excel 管理のように API で取得できない情報は必ず存在します。チャットへの一言報告（「A現場終わりました」）を受け口にし、スプレッドシートは定期取り込みで拾います。

全件連携を導入の前提条件にはしていません。3系統から始めて、価値を確認しながら広げるのが標準の進め方です。繋がっていない領域は、確信度が低い状態として正直に表示されます。

非構造データから状態を推定することが、数年前までは不可能でした。 チャットの雑談や議事録の断片から案件の状態を読むという処理は、大規模言語モデルの実用化によって初めて成立しました。この技術的前提の変化が、本構想の成立条件です。

加えて、少人数で多数を回すことが例外ではなく常態になったこと、主要業務ツールが API を備えたこと、そして「見える化したが何も変わらなかった」という失望が市場に蓄積したこと。可視化の次を求める需要は、すでに存在しています。

意思決定は、報告を待てない。