レビューする人がボトルネックになる
AI は一日で人の数倍を出します。その全部を人が読むのなら、速くなったのは生産であって、届けることではありません。レビューが遅れるほど、誤った前提の上に次の作業が積み上がります。
なぜプラットフォームが要るのか
AI がコードを書きはじめてから生まれた問題
モデルはすでに十分に書けます。詰まるのはその先です — 誰がレビューし、誰が責任を持ち、何が残るのか。
一台なら回る、十台は回らない
エージェント一台につきっきりになるのは誰にでもできます。十台が同時に動きはじめると、誰が何を取り、何が止まり、なぜ止まったのかが一目で見えません。止まったことに気づかないまま一日が過ぎます。
昨日学んだことが明日には消える
同じ落とし穴を来週また踏みます。チャット画面で得た教訓はチャット画面とともに消え、次の作業は何も知らないところから始まります。
製品
つくる仕事と、確かめる仕事を一緒に回す
SSemProHub はエージェントを賢くするものではありません。エージェントが出した結果を信頼できるものにする構造をかぶせます。
計画から承認まで一本の流れで
要件から作業リストを起こし、エージェントが取り、成果物を出し、採点を受け、人が承認して終わります。各段階が次の段階の入力になり、途中で止まった作業はひとりでに表に出ます。
八つの目が同時に見る
一つの成果物を、正確性・セキュリティ・性能・アーキテクチャ・品質・業務分析・プロセス・振り返りの八つの視点が並行して採点します。八つが受け取る資料はまったく同じで、違うのは見る目だけです。
同じ失敗を二度はしない
作業が終わるたびに、なぜ失敗し、なぜうまくいったのかを教訓として抜き出し、積み上げます。その教訓は次の計画書と次の採点に自動的に入ります — 人が探して読まなくても。
機能
運用で実際に使われているもの
モデルのルーティング表
機能 × モデルの表ひとつが、計画・分析の呼び出しと八つの採点視点のモデルを決めます。計画は大きなモデルで、採点はまた別のモデルで — 画面で変えればすぐに反映され、作業エージェントはモデルがデーモン設定に入っているため再インストールを一度はさみます。一つが使えなければ次のモデルへ移ります。
二系統のスコア合成
モデルの判定だけを信じません。ファイルが実在するか、大きさはどれほどか、といった機械的な計算を混ぜて最終スコアを出します。同じ入力に同じ点数を返しつづける固着を、この二つ目の系統が破ります。
異常の自動検知と自己復旧
点数が動かない作業、報告なく死んだエージェント、長く止まったレビューを 30 秒ごとに洗います。繰り返しの回数に応じて採点モデルを切り替え、それでも駄目なら人を呼びます。止まった理由は九つに分類されて画面にそのまま出ます。
六つの実行モード
無人で回るデーモンから、人が横で一つずつ確認するモード、複数人で画面を一緒に見るモードまで選べます。人が担当する仕事も同じ作業領域と同じ採点体系の上に載ります — 議事録も承認も成果物として残ります。
消えない記録
監査表はデータベースの側が更新と削除を直接止め、各行が前の行の指紋を受け継いで鎖をつなぎます。途中の一行に触れただけで、その後ろがすべて合わなくなり、すぐに露見します。同じ方式の鎖は AI の判断記録ですでに動いており、権限行為の監査表については、記録をつなぐ結線がこれからの課題として残っています。
メッセンジャーと音声で承認
レビューが終わると要約が携帯に届きます。ボタン一つで承認するか、手直しを求めます。声で尋ねて声で承認する音声アシスタントも同じ経路を使います — 席を外していても列は止まりません。
仕組み
タスク一件が通る道
要件が入ってきて承認で終わるまで、五つの段階がすべてプラットフォームの中でつながります。人が必ず要るのは最後の一つだけです。
1
計画
要件を読んで作業リストに分けます。それぞれの作業に、担当と先行条件と根拠資料が一緒に付きます。
2
割り当て
エージェントが自分で取っていきます。段階ゲート・先行作業・予算を通ったものだけが手に取れます。
3
実行
自分の作業領域で文書とコードをつくり、リポジトリに上げてから結果を報告します。
4
採点
八つの視点が同じ成果物を同時に見ます。スコアはモデルの判定と機械的な検証を混ぜて出します。
5
承認
人が通せば終わりです。なぜ通り、なぜ通らなかったのかは教訓として残り、次の計画に入ります。
八つが同じものを見て、違う読み方をする
八つに渡る資料はまったく同じです。違うのはプロンプト — 見る目だけです。そしてスコアは、モデルの判定ひとつでは決まりません。
図の読み方
- 左のひとつから八つへ分かれる線が、この図の要です — 八つが受け取る資料はまったく同じです。
- レビュアーはファイルを手渡されません。成果物が置かれた作業領域を自分で開いて読みます。
- 真ん中の箱で、モデルの判定と機械的な検証が混ざります。ファイルが実在するか、大きさはどれほどか、といったものです。
- 右の三つの分かれ道が結果です。通過は承認待ちへ、手直しは同じエージェントへ、解けなければ人へ向かいます。
- 下へ戻るオレンジの線が固着の検知です。同じ点数が繰り返されたら採点モデルを替えて、決定論を破ります。
構成
自社の境界の中で完結する設計
外部 SaaS なしに自社のサーバーで動きます — データベースもエンジンも画面もエージェントも、すべて境界の中にあります。外に出るのは LLM の呼び出しひとつだけで、どの提供元を使うかは表で選びます。
図の読み方
- 左から右へ四つの列です — 人、関門、エンジン、保存と実行。すべての矢印が社内の境界の中で終わります。
- 流れる点線が普段のトラフィックです。画面の操作もエージェントの報告も、関門で認証を通らなければエンジンには届きません。
- オレンジの点線だけが例外です。リアルタイムの音声会話は関門を迂回して、専用のブリッジに直結します。
- 中央で強調された列がエンジンです。Webhook API と照会ビューの上に、計画・採点・自動化が載っています。
- 右下の矢印は双方向です — エンジンがデーモンの起動と停止を指示し、デーモンは作業の報告をエンジンへ直接送ります。指示の経路が切れても、進行中の作業は動きつづけます。
導入
四歩で最初の作業が回ります
- 1
スタックを立ち上げる
データベースとエンジンと画面をコンテナで立てます。既存の社内認証とリポジトリはそのまま使えます。要るのはサーバー一台です。
- 2
ホストをつなぐ
エージェントを動かす機械に、コマンド一行で管理プログラムを入れます。macOS・Ubuntu・Windows すべて同じやり方で、余っているノート一台から始めてもかまいません。
- 3
エージェントを編成する
担当領域とモデルと実行モードを画面で決めます。作業領域とリポジトリ権限は自動でつくられます。人の担当者も同じ名簿に載せます。
- 4
現状把握から稼働まで
既存システムを読んで現状と目標を整理し、そこから作業リストをつくります。承認すればエージェントが取りはじめます。
技術
長く回すことを前提に選んだもの
Java 21 · OSGi
Apache Karaf の上のモジュール構造です。一つの機能を直すのに全体を落とさず、そのバンドルだけを差し替えます — エージェントが夜通し動いている最中でも。
PostgreSQL
作業・レビュー・教訓・監査を一つの保存先に置きます。スキーマは版を刻んで進み、監査表はデータベース自身が追記専用を強制します。
React 運用コンソール
進捗、レビュー履歴、成果物の本文、費用、異常の兆候を一画面で見ます。図もソースも別のツールを開かずその場で開きます。
モデルは選ぶもの
商用サブスクリプションと Ollama アカウントのモデルを併せて使います。どの仕事にどのモデルを使うかは表で決め、単価表で費用がすぐ確かめられます。
まず一つのプロジェクトで測ってください
いま進めている仕事の一つを、そのまま載せてみてください。計画が出て、エージェントが取りはじめ、採点がつくまでにどれだけかかるか — それが一番正確な答えです。
導入のご相談社内サーバーへの設置を基本とします。ご希望であれば当社が運用します。