01
品質アセスメント
まず見せてください。既存の開発フローと、生成されたコードの検証状況を診断します。何が危ないかを優先度付きで示し、品質規程の草案をお出しします。単独でも依頼できます。
作れた。次は「出していいか」を。
OriTech は、AI開発の独立検証を行います。実装した側とは別の系で要求・実装・検証を突き合わせ、本番に出してよいかを証跡付きで判定します。
仕様書がまだない、精度を信用してよいか分からない、LLMで一気に作ったので怖い。そういう状態から入れます。
OriTech は七夕研究所の技術ブランドです。
対応領域
決まったテスト仕様に従って実行する仕事ではなく、「何を確認したら出してよいのか」を決める仕事から入ります。
02
出荷判定レビュー
何をもって「出してよい」とするかを定義し、実際に検査して判定します。PASS / 条件付きPASS / BLOCK のいずれで出す場合も、判断の根拠を証跡として残します。
03
是正実装とハードニング
見つかったものを直すところまで対応します。欠陥の是正、検査ツールの実装、権限境界と不可逆操作の見直し。独立性を保つため、判定と是正は別契約・別担当で行います。
04
継続的品質エンジニアリング
CI の品質ゲート、評価データセットによる回帰検査、監視とロールバック手順として常設します。単発の検査で終わらせず、開発の速度を落とさない形で残します。
ソフトウェアとAIの出力を、まとめて見ます
「コードが正しいか」と「AIの判断・出力が正しいか」は別の品質問題です。担当が分かれていると、どちらでもない隙間に事故が残ります。OriTech は一本で見ます。
- 要求
- そもそもの要求と仕様が妥当か
- 生成コード
- LLMが書いた実装が正しいか
- テスト
- テストが自己撞着していないか、通っている理由が正しいか
- セキュリティ
- 権限設計、秘密情報の扱い、不可逆操作の承認境界
- LLM出力
- 回答品質、事実性、根拠の妥当性、指示遵守
- 評価基準
- その評価基準（rubric）自体が適切か
- エージェント
- 自律動作の権限境界と停止条件
- 運用
- 監視、ロールバック、障害時の判断手順
価格と、実際の成果物を公開しています
入口の Quick Scan は 50万円・定額です。判定レポートのサンプルは、自社システムを検査した実物を PDF で公開しています。
作る側の実務も持っています
検証だけの会社ではありません。以下の領域で受託開発の実務を続けているため、指摘して終わらせず、是正まで踏み込めます。
- データ基盤の構築（収集・統合・加工・可視化・運用）
- AI / 深層学習の PoC（モデル設計・評価設計・検証計画）
- CV・LLM を含む先端技術の業務適用
INDEPENDENT VERIFICATION
独立検証という進め方
LLMがコードを書く前提の開発では、ボトルネックは「書く速さ」ではなく「通してよいと判断する速さ」に移ります。 速度を落とす必要はありません。落とすべきなのは、根拠のない安心です。
こういう状況で使われます
LLMで一気に作った。動いてはいるが、エンタープライズの顧客に出す直前で怖くなった
生成される実装の量は増えたのに、レビューが追いつかない
「動いた」と「正しい」の区別が、現場の判断に委ねられたままになっている
PoCの精度は出ている。ただ、その数字を信用してよいのか社内で誰も判断できない
検証の原則
生成と判定を、担い手ごと分ける
実装したエージェントに「あなたの実装は正しいですか」と聞くのは検証ではありません。実装・反証レビュー・決定的なテスト・実環境での再現・出力のブラインド評価・最終判定を、それぞれ別の担い手に割ります。
成功結果も反証の対象にする
失敗だけでなく、通ったテストと高い精度も疑います。テストが自己撞着していないか、その精度が出てしまった理由が正しいか。良い数字が出たときこそ確認します。
リスクの階層に応じて独立度を上げる
全案件をフル装備にはしません。壊れたときの影響と不可逆性でリスクを階層化し、上位の階層だけ独立度と証跡の厚みを上げます。
判断基準を、人ではなく規程と検査に置く
要求・実装・試験をID体系で結び、欠落や未検証をCIで検出します。欠陥は個別修正で終わらせず、原因のクラスタへ抽象化して同じ型を横断探索します。
体制
人数ではなく、判断の階層で設計します。案件の規模とリスクに応じて組成します。
品質アーキテクト
品質規程の起草、リスクモデルと受け入れ基準の設計、出荷判定の最終判断。標準が存在しない領域に標準を作り、異常は原因のクラスタまで引き上げます。
セマンティック品質（LLM出力の評価）
言語・社会科学系のバックグラウンドを持つ担当が、LLMの出力そのものを評価します。評価基準の設計、ゴールデンセットの作成、事実性、根拠の妥当性、指示遵守、文体、法務的な過剰断定、誤解を招く表現、そして「根拠は正しいが回答として不適切」な事例の判定。LLMを評価に使う場合も、所見を出すところまでにとどめ、深刻度と観点判定の確定は人間が行います。ソフトウェア工学だけでは閉じない領域です。
検証セル（フルタイム2名）
毎日稼働し、必要に応じて現地に入れる体制です。検証プロトコルの実行、欠陥の再現、ログ収集、E2Eと回帰、トレーサビリティの確認、CIへの組込み、是正後の再検証。判断が必要な箇所は品質アーキテクトへ上げます。
LLM（実装・テスト生成・調査）
実装、テスト候補の生成、ログ解析、同型欠陥の探索、文書生成、出力評価の一次通し。量を出す側の担い手です。深刻度と判定値の確定には使いません。
独立性について
当社が独立と呼ぶのは、次の2つを両方満たす状態です。1つは対象からの独立で、判定の対象を作った側と、判定する側が別の系にいること。もう1つは結論からの独立で、判定の結論が当社の売上に影響しない構造になっていることです。
後者のために、判定と是正を同一契約・同一担当では受けません。BLOCKが追加受注につながる構造を作らないためです。 是正をご依頼いただく場合は別契約・別担当とし、再判定は是正を担当していない者が行います。 当社が実装に関与した対象について、当社は判定を出しません。判定値に応じて報酬が変わる契約も締結しません。 開発会社・SIerからのご紹介の場合は、紹介元の同意なく、その顧客へ開発案件を提案しません。
契約は準委任を基本とし、指揮命令は当社が持ちます。成果物は検証の証跡と判定レポートです。規模と期間に応じて見積します。
当社が提示するのは、証拠に基づく技術判定です。法的な保証・認証ではありません。最終的なリリースの意思決定はお客様に帰属します。判定レポートには必ず未検証範囲と限界を記載します。
実績（一部抜粋）
いずれも作る側として関わった案件です。検証の指摘が実装として成立するかを判断できる根拠として挙げています。
大手小売チェーン
データ基盤構築（業務データ統合・分析基盤）
東証プライム上場企業
情報サービスにおける深層学習PoC
AIベンチャー
CV・LLMを用いた先端技術PoC
詳細は守秘義務の範囲で、初回相談後に共有できる場合があります。
進め方
- 1
ヒアリング（30–60分）
対象システム、期限、そして「何が壊れると困るか」を確認します
- 2
品質アセスメント
現状を診断し、リスクの階層、検証計画、品質規程の草案を提示します
- 3
検証設計
何をもって「出してよい」とするかを決めます。受け入れ基準、LLM出力の評価基準、トレーサビリティの定義
- 4
検証と判定
機械検査・人手の検証・出力のブラインド評価を実行し、PASS / 条件付きPASS / BLOCK を証跡付きで報告します
- 5
是正・常設化
是正実装（別契約）、または CI の品質ゲートと回帰検査として常設し、引き渡します
よくある相談
仕様書がありません。それでも依頼できますか?
そういう状態が前提です。要求と制約を先に言語化し、何を確認したら出してよいのかを定義するところから入ります。
実装は自社で行い、検証だけを依頼できますか?
可能です。まず品質アセスメントで現状の検証状況を診断し、規程の草案と優先度をつけた改善案をお出しします。
開発と検証を同じ会社に頼んで、独立性は保てますか?
判定と是正を同一契約・同一担当では受けません。是正は別契約・別担当とし、再判定は検証側の担当が行います。BLOCKが追加受注につながる構造を作らないためです。
「出せない」と判定されることはありますか?
あります。条件付きPASSやBLOCKの場合も、判断の根拠を証跡として提示します。判定を通すこと自体を目的にはしません。
LLMの回答品質そのものを評価してもらえますか?
対応します。評価基準の設計、ゴールデンセットの作成、人間によるブラインド評価まで行います。言語・社会科学系のバックグラウンドを持つ担当が入ります。
常駐や、既存チームとの並走は可能ですか?
フルタイムで稼働する検証担当が2名います。必要に応じて現地に入る形も相談できます。契約は準委任を基本とし、指揮命令は当社が持ちます。
PoCの段階から相談できますか?
可能です。「次の意思決定に繋がるPoC」になるよう、評価設計を重視します。精度が出たときに、その数字を信用してよいかまで見ます。
NDAは対応できますか?
対応できます。初回相談後に必要に応じて締結します。
まずは状況をお聞かせください
「LLMで作ったので見てほしい」だけでも構いません。対象システム・期限・気になっている点が分かる範囲で送ってください。初回は無料で整理します。