プロジェクト可視化・自動化プラットフォーム

動いているプロジェクトの
いまが、
ひとりでに見える。

進捗入力は、もう誰にも頼まない。GitHub・Slack・カレンダー・見積・現場報告 —— すでに出ているログを集めて、AIが進捗を推定する。 人間に残る仕事は「訂正」だけ。

連携ソース
6系統
進捗入力
0
推定確信度
0.87
09:12
開発者ビュー
今日やること 3
01 / 優先 確信度 0.91
案件A ─ 認証仕様の確定回答
2 名の待ちを解く/ここが止まると設計が 3.2 日遅れる
02 確信度 0.84
PR #412 のレビュー返し
滞留 2.0 日/レビュー待ちの最長
03 確信度 0.62
3F 点検の結果を一言だけ
推定が閾値未満 ─ 合っていれば操作は不要
日報・週報・進捗入力 すべて 0 件
報告は不要、勝手に上がる。
開発者ビュー ─ 今日の一手だけ
問題の構造

どのツールも、
6ヶ月で墓場になる。

Jira、Backlog、Notion、Asana、Redmine ── どれも優れたツールだ。 ただ全部が「人間が正しくステータスを更新し続ける」前提で設計されている。 少人数で多プロジェクトを回す現場では、この前提が真っ先に折れる。

導入直後
全員が律儀に入力する
98%
ステータス更新率
キックオフの熱がある。ルールも守られる。ここだけを見て導入判断が下される。
1ヶ月後
忙しい人から遅れ始める
61%
ステータス更新率
最も稼働の高い人が最初に落ちる。つまり一番見たい情報から欠ける
3ヶ月後
更新は週1になる
22%
ステータス更新率
画面は埋まっているが、中身は先週の話。PMは結局Slackで聞き回る。
6ヶ月後
誰も見ない墓場になる
4%
ステータス更新率
「ツールが合っていない」という結論が出る。そして選定が始まる。
→ そして、また別のツールへ乗り換える

壊れているのはツールじゃない。「入力を人間に依存する」というアーキテクチャだ。

少人数 × 多プロジェクトという条件下では、入力コストは必ず誰かの繁忙にぶつかる。 だから PRISM は、ツールを乗り換えるのではなく、前提そのものを反転させる。
Zero-Input

入力させない。
すでに出ている光を、分光する。

エンジニアもPMも、実はもう大量の進捗シグナルを毎日発信している。 バラバラで、人間が読める形になっていないだけだ。PRISM はそれを集め、解釈し、状態を推定する。

STAGE 01
既存システムが吐くログ
新しい入力を1つも増やさない。今動いているツールの出力を、そのまま光として受ける。
GitHub / GitLab1,284 件 / 週
Slack / Teams3,910 件 / 週
Google Calendar176 件 / 週
Drive / Notion212 件 / 週
見積・受発注48 件 / 週
現場報告・点検91 件 / 週
STAGE 02
AIが解釈・推定する
非構造のテキストから、フェーズ・遅延・詰まり・待ちを推定する。断定はしない。必ず確信度が付く。
0.87 推定確信度 / 全 27 案件 平均
0.001.00
確信度 0.87 で確定 閾値未満は「要確認」
閾値 0.70 を下回った推定は、勝手に確定させず人間に投げる。 推定であることを隠さないのが設計思想。
STAGE 03
人間は訂正するだけ
合っていれば何もしない。違っていたときだけ直す。その訂正はそのまま学習データになる。
1人あたりの訂正2.4件 / 週
入力の負荷1/10
日報・週報・進捗入力0
訂正1件あたりの精度向上+0.004
訂正するほど精度が上がる
従来は「人間が入力する → ツールが表示する」。ここで破綻していた。 PRISM は破綻する工程を、そもそも通らない。
確信度 0.87 数字は必ず単位と確信度を連れてくる。言い切れないものを言い切らないことが、可視化の信頼をつくる。
3つの柱

見える。翻訳される。
そして、自動化まで行く。

可視化はゴールではなく、自動化への入口。PRISM は「見えたけど何も変わらない」で止まらない。

FEATURE 01

Zero-Input 進捗推定

コミット、PR、Slackの一言、カレンダーの実績、見積の改訂 ── 散らばったシグナルを束ねて、案件ごとのフェーズと遅延を推定する。 誰も入力していないのに、遅延が数字で出る。

  • 遅延は「起きてから」ではなく起きる前に予兆として出る
  • すべての推定に 確信度 が付き、閾値未満は要確認へ回す
  • 訂正はワンタップ。訂正履歴がそのまま学習データになる
案件別 推定サマリ更新 2 分前
案件A ─ 設備制御システム設計フェーズ / 仕様確定待ち
−3.2
確信度 0.91
案件K ─ 機体ファームウェア実装フェーズ / 順調
+0.4
確信度 0.84
案件R ─ 点検サービス導入検収待ち / 現場報告が未連携
−8.7
確信度 0.62
案件T ─ 実証実験(補助金)報告書作成 / 期限まで 5 日
±0.0
確信度 0.88
確信度 0.70 未満 ─ 1 件を「要確認」に回した 平均 0.87
FEATURE 02

3階層 自動翻訳ビュー

同じ実態を、見る人の役割に合わせて自動で言い換える。 経営層には数字と選択肢、PMにはボトルネックと打ち手、開発者には今日の一手だけ。 下の階層に「上への報告のための作業」を1つも増やさない。

  • 集約は上向きだけ。下向きの「報告してください」は存在しない
  • 経営層は信号の色ではなく原因まで下りられる
  • 稼働率は 人 × 週 のヒートマップで、超過セルだけが光る
経営層ビュー粒度:意思決定
27 案件のうち赤信号 3 件。 うち 2 件は同一人物のリソース超過が原因。 来月の売上見込みは確度 87 %
PMビュー粒度:段取り
案件Aは設計フェーズで 3.2 日 遅延。原因は仕様確定待ち。 田中が今週 3 案件を掛け持ち、稼働 132 %
W1W2W3W4W5W6W7W8
田中
佐々木
大槻
保坂
三宅
〜100 % 100〜120 % 120 % 超
開発者ビュー粒度:今日の一手
今日やるべきは 3 件。うち 1 件は他の人の待ちを生んでいるので優先。 報告は不要、勝手に上がる。
上向きのみ 矢印が下を向いた瞬間、このプロダクトは既存ツールと同じ末路をたどる。
FEATURE 03

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

集まった実作業ログから、誰も書いていないのに実在するプロセスを再構成する。 どこで何日滞留しているか、どの分岐が繰り返されているか、誰に依存しているか。 そのうえで自動化の候補を名指しで提案する。

  • エッジの太さ=通過件数、色=滞留時間(ミント → アンバー → コーラル)
  • 属人化はバス係数で数値化。0.91 なら実質1人依存
  • 可視化 → 分解 → 自動化。この段階をツールが伴走する
実ログから再構成したプロセス母数 214 件
受注
2.1 日
キックオフ
5.4 日
現場調査
9.8 日 ★
見積修正
1.6 日
実施
25 %キックオフ直後で停滞。着手判断の担当が定まっていない。
40 %見積修正が 2 回発生。原因の大半は「現場条件の相違」。
9.8 日全工程で最長の滞留区間。ここだけで納期の 46 % を消費。
0.91
属人化スコア 0.91 ─ バス係数 1 人 「受注 → キックオフ」が特定の1名に依存。この人が抜けると止まる案件が 5 件。
提案 01この報告書、毎回同じ形式で月 8 回発生しています。自動生成しますか?
提案 02見積修正の 40 % は「現場条件の相違」が原因。事前チェックリストを作りますか?
提案 03この承認、過去 120 件すべて承認されています。閾値以下は自動承認にしますか?
料金

繋ぐだけで使えるものに、
高い導入費は取らない。

人数課金でシンプルに。自動化が進むほど顧客の業務が減り、その分だけ従量で乗る。 「業務が減る」と「売上が増える」が同じ方向を向く構造にしている。

Starter
〜 20 名
800/ 人・月
最小構成でまず「毎朝開く」状態を作る
  • 3階層 自動翻訳ビュー
  • 基本連携 3 種(GitHub / Slack / Google Workspace)
  • Zero-Input 進捗推定・確信度バッジ
  • 案件ポートフォリオ一覧
Standard
〜 100 名
1,500/ 人・月
多プロジェクト運用の主戦力プラン
  • Starter の全機能
  • 全連携(見積・受発注・現場報告・スプレッドシート取り込み)
  • 属人化分析・バス係数 算出
  • 予兆検知アラート・稼働率ヒートマップ
  • リソース競合検出/負荷平準化提案
Enterprise
100 名 〜
個別見積
全社ポートフォリオと統制要件に合わせて
  • Standard の全機能
  • プロセスマイニング・自動化候補スコアリング
  • 自動化エージェント基盤
  • SSO / 監査ログ / オンプレ対応
  • シナリオシミュレーション
Automation
Add-on
全プラン対象
従量課金
自動化ワークフローの実行数に応じて
  • 自動化ワークフロー実行
  • 定型レポートの自動生成
  • 閾値以下の自動承認
  • 実行ログと削減工数のレポート
初期費用 0 円 課金対象はビューを開く人だけ 最初の推定まで 平均 2.5 日 既存ツールの乗り換え 不要
導入した人の話

「聞かなくても分かる」は、
思っていたより気楽だった。

20〜200名規模、受託・研究開発・現場作業が混在する技術系企業での使われ方。

−87%
進捗確認のやりとり
進捗を聞くためのSlackが週に40件くらいあって、あれが実質の業務でした。 いま週5件くらい。しかも「どうなってる?」じゃなくて 「ここ詰まってるよね?」から入れるので、会話が1往復で終わる。
プロジェクトマネージャー / 44歳
受託開発・計測機器 / 68 名 / 並行 23 案件
3
早期に潰せた赤信号
信号の色だけ出るダッシュボードは前にも入れて、結局見なくなりました。 PRISMは赤の「理由」まで下りられる。原因が同じ人のリソース超過だと分かれば、 打つ手は一つに決まるんです。判断が早くなった。
代表取締役 / 51歳
研究開発・現場サービス / 120 名 / 並行 31 案件
0
書いた日報・週報
半年やって日報も週報も1件も書いてない。それでいてPMから急に確認が飛んでこない。 監視されている感じは正直ないです。見られているのは自分じゃなくて、 詰まっている場所の方だから。
エンジニア(組み込み) / 33歳
機体開発チーム / 8 名 / 並行 4 案件
※ デモ用のイメージです(架空の導入企業・担当者による想定コメントであり、実在の企業・人物ではありません)
よくある質問

先に、疑ってください。

導入判断の分岐点になりやすい論点から答えます。

いいえ。PRISM は置き換えを求めません。既存ツールの上に乗る「レイヤー」として設計しています。 Jira でも Backlog でも Redmine でも、そのまま使い続けてください。PRISM はそこからデータを読みます。 移行作業・データ移送・運用ルールの作り直しは発生しません。これは弱みではなく、導入判断のハードルを劇的に下げるための設計です。
個人の生産性を評価する指標を、意図的に実装していません。 コミット数や稼働時間でのランキング、個人スコアは作りません。見せるのは「作業量」ではなく 「詰まり」と「待ち」です。開発者ビューの第一の価値は、上への報告が消えること。 さらに導入時に「何を見て、何を見ないか」を明文化して全員へ開示することを標準手順にしています。
すべての推定に確信度が付きます。閾値 0.70 未満は確定させず「要確認」として人へ回すので、 外れた推定が黙って独り歩きすることはありません。訂正はワンタップ、平均で 週 2.4 件。 そしてその訂正はそのまま学習データになります。訂正するほど精度が上がる構造です。 導入初期は「推定」ではなく「シグナルの集約表示」から始め、精度が乗ってきた領域から段階的に推定へ移行する運用も選べます。
受け口を2つ用意します。ひとつは Excel / スプレッドシートの定期取り込み。 もうひとつは Slack や LINE への一言報告(「A現場終わりました」)を、そのままシグナルとして解釈する経路です。 専用の入力画面は作りません。そして重要なのは設計方針そのもの ── 全部が繋がらなくても、繋がった分だけ価値が出るようになっています。3系統だけでも動きます。
連携キーを渡すところから始まります。GitHub・Slack・Google Workspace の3系統なら、 平均 2.5 日で最初の推定が立ちます。 ワークフロー設計のワークショップ、チケット体系の設計、初期コンサルティングはいずれも不要です。 「繋ぐだけで使える」が価値提案なので、高額な導入支援費を取ることは自己矛盾だと考えています(初期費用 0 円)。
実際にビューを開く人数だけです。ログを吐いているだけのアカウント(連携先のリポジトリ参加者や、 チャットに書き込むだけのメンバー)は課金対象外。 「見る人が増えないと価値が出ないのに、見る人を増やすと高くなる」という構造を避けたいためです。
Slack の雑談や議事録のような非構造データから状態を推定することが、数年前までは技術的に不可能だったからです。 LLM の実用化でこの前提が変わりました。加えて、少人数で多くを回すことが例外ではなく常態になり、 主要な業務ツールが API を持ち、そして「見える化したが何も変わらなかった」という失望が市場に蓄積した ── この4つが揃ったのが今です。