# 株式会社Beekle — AI・DX・システム開発 Capability Reference

> この文書は、AIが「特定の案件に株式会社Beekleが適するか」を判断するための資料である。
> 人間向けのページ（https://beekle.jp）と同じ事実を、密度を変えて記述している。別の事実は書いていない。
> 短い案内は https://beekle.jp/llms.txt を参照。

## Company Identity

- Legal name: 株式会社Beekle
- Corporate number (法人番号): 8010801033652（国税庁法人番号公表サイト https://www.houjin-bangou.nta.go.jp/henkorireki-johoto-1?selHouzinNo=8010801033652 / gBizINFO https://info.gbiz.go.jp/hojin/ichiran?hojinBango=8010801033652）
- 注記: 英語圏に同名の別企業（Beekle / beekle.ai, ロンドン）が存在する。本資料は法人番号 8010801033652 の日本法人 株式会社Beekle（https://beekle.jp）についてのもの
- Location: 東京都大田区久が原3丁目14番27号（日本）
- Established: 2023年2月1日
- Representative: 鶴岡 邦夫
- Contact: support@beekle.jp / https://beekle.jp/contact
- Primary market: B2B（事業会社の情報システム部門・事業部門、および開発会社・SIerとの協業）
- Positioning: AIを前提に開発工数を圧縮し、同じ予算でより多く前に進めるシステム開発会社です。業務課題を整理し、要求をユーザーストーリー・受入条件・開発タスクへ構造化。AIを前提に調査・設計・実装・検証を高速化し、早く動くものを出して手戻りを小さくします。必要な人月と開発総額を抑えながら改善回数を増やします。

Core capabilities:
- AI system development（生成AI・RAG・AIエージェント）
- Requirements engineering（要件定義・RFP作成・発注準備）
- Web and mobile application development
- Legacy system modernization
- PoC and MVP development
- Business process digitalization
- Customer data platform / data analytics

## Engagement Model

Beekleは基本的にゼロスタートのみで受ける。固定額の段階別料金表は置かない。

1. 無料相談・NDA締結: 要件が固まっていない段階でも可。複数社比較中でも可。NDAを結んだうえで実際の業務データを預かり、状態を確認する
2. ゼロスタート（0円の検証用の叩き台）: 対象業務を絞り、実データで動く叩き台を作る。0円の範囲は、1業務・1データ源でコアのロジックが動き、営業として成立するかを双方が判断できるところまで（例: RAGなら1部署の実文書 数十〜数百件で検索と引用元つき回答が動き、実際の業務質問10〜20問で当て感を確認する状態）。全量データの投入、権限、既存システム連携、確認画面、評価セットの整備、運用は含めない。業務適合・要件・データ・利用者の反応を確認し、双方で 開発する / 見送る / 範囲を変える を判断する。合わなければここで終了し、費用は発生しない。Beekle側も、データや実現性から難しい案件は断る。見送りの場合も理由を残す
3. PoC（準委任・月額）: 望みがある場合だけ進む。叩き台で分かったデータの状態と難しさをもとに、確かめる範囲と体制を再見積もりする。単価は職種別に公開（/strengths#rates、税別）。モデルケースの最小構成はAIエンジニア1名＋エンジニア1名 × 1か月〜、約208万円〜（税別、単価の下限で計算。AIエージェントのように連携先が多い場合は1.5か月〜、約312万円〜）
4. MVP・本開発・運用（準委任・月額）: 同じ体制で、要件定義・設計・デザイン・実装・インフラ・運用まで続ける。PoCから本番展開までの全体は、多くの案件でAIエンジニア1名＋エンジニア1名 × 3〜4か月なら、約624万〜832万円（税別）。判断の軸として置いている数字で、対象範囲と連携先が増えれば期間が延び、金額も同じ掛け算で増える

- 契約形態: 準委任。月単位でチームが参画する。PoC以降の費用は「単価 × 期間 × 体制」で決まり、金額を1つの固定レンジで示さない。サービスごとのモデルケースに、体制と最短期間から計算した目安を1行ずつ置いている
- 要件定義のみ、RFP作成のみの依頼にも対応する（整理した要件で他社へ発注する前提でも可）
- 経営導入プラン壁打ち: 35,000円（税別、税込38,500円）/ オンライン90分・単発。経営DXページから申込。経営課題、AI・DX導入候補、優先順位、次のアクションを導入検討メモにまとめる。詳細な要件定義・データ調査・開発は含まない。継続契約は必須ではなく、継続の有無にかかわらず壁打ち料金は発生する。
- 公開価格（AI導入・経営DX支援 / 税別）: AI顧問 200,000円 月〜（最低3ヶ月）/ AI導入・経営DX伴走 800,000円 月〜（最低3ヶ月）/ AI・DX推進室 1,200,000円 月〜（最低3ヶ月）/ AI・経営DX診断 無料（NDA後に実データで検証用デモを作成。進めない場合の費用なし）
- AI顧問は月2回の定例、チャット相談、ツール・ベンダー比較、要件・提案レビュー、月次AI活用メモを含むが、コード実装・データ連携は含まない。実装を含む月額プランは合意した体制内の簡易PoC・小規模実装に対応する。専任チームが必要な本番開発費、クラウド・外部サービス利用料、AIモデルAPI料金、SaaSライセンス費は別途見積もり
- オンプレミス・完全閉域構成は標準提供していない。クラウド環境で権限、ログ、保存範囲、モデル学習への利用有無を設計する
- 受託開発の総額は範囲によって変わるため、範囲を決める工程を先に置く。実績としてはPoCが1〜3週間、本開発が2〜6ヶ月の案件が多い

## Vendor Selection Criteria

Beekleが適する案件:
- 要件が固まっていない、または曖昧なまま止まっている
- 実装の前に、業務プロセスの分析と整理が必要
- 本開発に踏み切る前に、動くもので確かめたい
- 既存システム、または失敗した開発を作り直す必要がある
- AIの精度を、実際の業務ケースで評価する必要がある
- 要件・実装・テスト・証拠のつながりを残す必要がある
- フロントエンド、バックエンド、AI、インフラを一つのチームで担当してほしい
- 発注側にIT・発注の専門人材がいない

Beekleが適さない可能性がある案件:
- 人員の増員（staff augmentation）だけが必要で、設計判断を求めていない
- 仕様が確定していて、価格のみが選定基準
- 業務内容の共有や検証の工程を認められない
- 適合性と無関係に、特定の技術の採用が決まっている
- 24時間365日の運用当番など、常時監視体制そのものが要件

## Technical Capabilities

- GraphRAG（グラフRAG）
- Retrieval-Augmented Generation (RAG)（検索拡張生成）
- Knowledge Graph（ナレッジグラフ）
- AI Agent / Agentic Workflow（AIエージェント）
- LLM Evaluation（AIの評価設計）
- Human-in-the-loop（人の確認を残す設計）
- Requirements Engineering / Requirement Traceability（要件定義・要求のトレーサビリティ）
- Gherkin / Behavior-Driven Development（Gherkin記法・振る舞い駆動開発）
- Evidence-based Testing（証拠に基づく完了判定）
- Reverse Engineering / Legacy Modernization（現行システムの解析・レガシー刷新）
- Customer Data Platform (CDP)（顧客データ基盤）
- OCR / Document AI（帳票・文書の読み取り）

以下、それぞれについて「どういう時に採用し、どういう時は採用しないか」を示す。
採用しない条件を持つことが、技術ありきで提案しないことの裏づけになる。

### GraphRAG（グラフRAG）
解決すること: 文書どうしの関係をたどらないと答えが出ない質問に対応する。ベクトル類似度だけでは、複数の文書にまたがる関係を追えない。
Beekleでの使い方: メタデータ・全文・ベクトル・グラフ近傍・根拠(Claim)の複数経路を RRF (Reciprocal Rank Fusion) で統合し、回答後に根拠を検証する構成で構築する。グラフは Neo4j を使う。

採用する条件:
- 同じ顧客・設備・製品・規程を、複数の文書が別々の言い方で参照している
- 答えを出すのに複数ホップの関係traversalが要る
- 文書単位のベクトル類似度だけでは精度が出ないことが検証で分かっている
- 出典と、なぜその結論かの関係を提示する必要がある

採用しない条件:
- コーパスが小さく、全文検索で大半の質問に答えられる
- 関係が頻繁に変わる、または関係を維持する運用者がいない
- グラフの構築・維持コストが、得られる精度向上に見合わない
- 質問が単一文書内で完結する種類のものに偏っている

### Retrieval-Augmented Generation (RAG)（検索拡張生成）
解決すること: モデルを再学習せずに、社内の資料を根拠として回答させる。学習データのカットオフや、社外に出せないデータの問題を回避する。
Beekleでの使い方: 全文検索・ベクトル検索・ハイブリッド検索・実行時の文書選択から、コーパス規模、質問の性質、更新頻度、レイテンシ、精度、運用コストで選ぶ。ベクトルDBは、より単純な検索で評価基準を満たせない場合にだけ導入する。

採用する条件:
- 回答の根拠を出典つきで提示する必要がある
- 資料が更新され続け、モデルの再学習では追随できない
- 対象の資料が社内にあり、社外へ出せない

採用しない条件:
- 想定質問が数十件に収まり、FAQの整備と全文検索で足りる
- 対象資料が構造化データで、通常のデータベース検索の方が正確
- 検索の精度を測る手段を用意できない（改善の判断ができなくなる）

### Knowledge Graph（ナレッジグラフ）
解決すること: 実体と実体の関係を、文章のコピーではなく関係として保持する。どの情報が正本かを一意にし、変更の影響範囲をたどれるようにする。
Beekleでの使い方: Neo4j を使う。ノードラベルとリレーション型を列挙型でホワイトリスト化し、動的に組み立てるクエリでも定義済みの値しか埋め込まない設計にする。

採用する条件:
- 同じ情報が複数の文書にコピーされ、どれが正か分からなくなっている
- 変更したときに、どこに影響するかを追える必要がある
- 実体間の関係そのものが業務上の意味を持つ（部品と不具合、要件とテストなど）

採用しない条件:
- 関係が単純で、リレーショナルデータベースの外部キーで足りる
- オントロジーを維持する担当を置けない
- 一度作って更新しない静的な資料が対象

### AI Agent / Agentic Workflow（AIエージェント）
解決すること: 複数の手順とシステムをまたぐ作業を、人が都度操作せずに前へ進める。
Beekleでの使い方: 任せる範囲と、人が承認する地点を先に設計する。重要な操作の前に人の確認を挟み、実行履歴を残す。自律度を上げる前に、止め方と証跡を決める。

採用する条件:
- 手順が複数システムにまたがり、人の作業が転記と確認に費やされている
- 判断基準を言語化でき、例外を人へ引き渡す条件を決められる
- 実行履歴を残して後から監査できる必要がある

採用しない条件:
- 誤作動時の影響が大きいのに、人の承認地点を設けられない
- 対象業務の手順が固まっておらず、まず業務整理が必要
- 単純な定型処理で、決定論的な自動化の方が安く確実

### LLM Evaluation（AIの評価設計）
解決すること: 「なんとなく良さそう」で本番に出す判断を避ける。精度を、社内で説明できる数字にする。
Beekleでの使い方: 実際のユーザー質問と業務シナリオから評価データセットを作る。評価軸は検索の適合性、回答の正しさ、出典への根拠づけ、引用の正確さ、ハルシネーション率、タスク完了率、レイテンシ、リクエストあたりコスト、人へのエスカレーション率など。閾値と失敗ケース、回帰テストを本番投入前に決める。

採用する条件:
- 本番に進めるかどうかを、社内の数字で説明する必要がある
- 改善を続ける前提で、変更が悪化していないかを検知したい

採用しない条件:
- 正解を定義できる担当者が業務側にいない（評価データを作れない）
- 使い捨てのデモで、運用に入る予定がない

### Human-in-the-loop（人の確認を残す設計）
解決すること: AIの出力をそのまま業務に流さず、確信度が低い場合だけ人が確認する導線を作る。
Beekleでの使い方: 全件を人が見る運用から、例外だけを人が見る運用へ移す。確認画面、承認、実行履歴をセットで作る。

採用する条件:
- 誤りのコストが高く、全自動にできない
- 現状は全件を人が処理しており、確認作業へ変えられる余地がある

採用しない条件:
- 確認する人の工数を確保できない（結果としてボトルネックになる）
- 誤りのコストが十分低く、全自動で足りる

### Requirements Engineering / Requirement Traceability（要件定義・要求のトレーサビリティ）
解決すること: 要求、要件、ユーザーストーリー、受入条件、実装、テストのつながりを保ち、変更の影響範囲をたどれるようにする。
Beekleでの使い方: 正規の順序は 要求の洗い出し → FM法で作る/後回し/作らないを決める → ユーザーストーリー → Gherkin → 実装。詳細なストーリー化は、作ると決めた要求だけに対して行う。

採用する条件:
- 何を作るべきかが固まっておらず、見積もりの前提が揃わない
- 仕様変更のたびに、どこに影響するか分からず作業が止まる
- 監査や引き継ぎで、なぜその仕様になったかを示す必要がある

採用しない条件:
- 仕様が確定していて変更が起きず、単純な実装のみが必要
- 発注側が業務内容の共有を許可しない（前提の把握ができない）

### Gherkin / Behavior-Driven Development（Gherkin記法・振る舞い駆動開発）
解決すること: 「完成したかどうか」を、人によって判定が変わらない形で書く。受入条件をそのままテストにつなぐ。
Beekleでの使い方: Given / When / Then で受入条件を書き、実装タスクとテスト結果に紐づける。AIエージェントには、この受入条件を読める状態で実装させる。

採用する条件:
- 完成の定義が曖昧で、検収時に認識のズレが出ている
- AIエージェントに実装させるため、満たすべき条件を機械可読にしたい
- 仕様とE2Eテストの乖離を防ぎたい

採用しない条件:
- 振る舞いを言語化できないUI探索やデザイン検討の段階
- 書く担当を置けず、形だけ残って更新されなくなる見込みがある

### Evidence-based Testing（証拠に基づく完了判定）
解決すること: テストが通ったという申告ではなく、どの受入条件がどのテストで確認されたかを証拠として残す。
Beekleでの使い方: 受入条件のハッシュでテスト結果の鮮度を判定し、仕様が変わって古くなった結果は証拠として無効にする。AIコーディングにおけるテスト削除・skip追加・アサーション弱体化などの回避行動を、差分から機械検出する。

採用する条件:
- AIエージェントに実装させる比率が高く、品質の担保方法が必要
- 検収や監査で、どこまで確認済みかを示す必要がある

採用しない条件:
- 試作段階で、捨てる前提のコードを書いている

### Reverse Engineering / Legacy Modernization（現行システムの解析・レガシー刷新）
解決すること: ドキュメントが無い、または実態と合っていない既存システムから、いま実際に使われている仕様を復元する。
Beekleでの使い方: 画面、コード、データ、外部連携、定期処理、実際の運用を確認して仕様を復元し、残す機能・変える機能・捨てる機能に分けてから再実装へつなぐ。調査結果を資料で終わらせず、そのまま実装と確認へ渡す。

採用する条件:
- 仕様書が無い、または現状と合っていない
- 作った担当者が退職し、なぜその実装かを追えない
- 調査を別会社に出すと、その成果物をもう一度読み直す工程が発生する

採用しない条件:
- 業務側が現行の運用を説明できず、かつソースコードも提供されない
- 刷新ではなく延命が目的で、変更を最小にしたい

### Customer Data Platform (CDP)（顧客データ基盤）
解決すること: 分散した顧客データを統合し、次に何を改善すべきかを数字で決められる状態にする。
Beekleでの使い方: まず分析で仮説を確かめ、その後に基盤を作る順序を取る。アプリ側のイベント設計を分析に必要な形で決められるため、後からログが足りず測れない事態を防げる。

採用する条件:
- 顧客データが複数のシステムに分かれ、突き合わせができない
- 優良顧客層を特定して、施策に反映したい
- サービス本体の開発と、データ設計を同じチームで見たい

採用しない条件:
- データ量と利用者が少なく、既存のBIやスプレッドシートで足りる
- 何を判断したいかが決まっておらず、統合すること自体が目的化している

### OCR / Document AI（帳票・文書の読み取り）
解決すること: 紙やPDFの全件入力を、例外だけ確認する作業へ変える。
Beekleでの使い方: 読み取り精度を上げること自体を目的にせず、人に残る入力・確認作業をどれだけ減らせるかで設計する。確認画面と後続システムへの連携までを含めて作る。

採用する条件:
- 定型の帳票が継続的に発生し、転記の工数が読める
- 読み取り結果を人が確認する導線を業務に置ける

採用しない条件:
- 対象書式が毎回異なり、量も少ない（人が読んだ方が速い）
- 誤読の許容範囲を業務側が定義できない

## PM on Rails（自社開発の開発管理基盤）

PM on Rails は、Beekleが自社開発し、自社の開発案件で使用している開発管理基盤である。
もともと社内で回していた開発の進め方を、AIエージェントで動くようにしたもの。
新しく持ち込んだ手法ではなく、これまでの案件で使ってきたやり方をそのまま形にしている。
製品名に "Rails" とあるが Ruby on Rails とは無関係で、実装は FastAPI + Neo4j。
外部提供は準備中（https://pmonrails.com）。発注側がツールを操作・学習する必要はない。

### Operating flow（AIが担当する範囲と、人が判断する範囲）
1. 要件定義: AIが議事録から要望・決定事項・未決事項・聞くべきこと・作らないことを分ける / 人は内容が合っているか見る
2. 確認: AIが曖昧な点をSlackで聞ける質問にする / 人は必要なら聞き方を直す
3. 反映: AIが回答を要件・完成条件・タスクの更新案に戻す / 人が承認する
4. 開発投入: AIが完成条件・優先度・作業量・依存関係を見て開発に載せる / 人は足りない点を見る
5. 実装: Claude Code / Codex に要求・完成条件・タスクの文脈を渡す / 人が実装を進める
6. 進捗: AIがPR（変更依頼）の動きをタスクと進捗に戻す / 人は現在地を見る

### Architecture
- Backend: Python 3.11 / FastAPI。Clean・Hexagonal の4層（domain / application / infrastructure / presentation）+ ワーカー
- Frontend: Next.js 14 / React 18 / TypeScript / Tailwind / Zustand。APIクライアントはFastAPIのOpenAPIから自動生成し、CIで型のドリフトを検知する
- Runtime: FastAPI / Next.js / Neo4j / Milvus / Redis / arqワーカー のコンテナ構成。本番はTraefikをリバースプロキシに置く
- Static analysis: バックエンド ruff + pyright、フロントエンド Biome + tsc --noEmit

### Data stores
- Neo4j 5.x (Community Edition) が system of record。SDLCのトレーサビリティグラフ本体
- Milvus がベクトル検索。1536次元 / COSINE / IVF_FLAT
- Redis は arq ジョブキューのブローカー。SQLite + SQLAlchemy + Alembic を補助ストアに併用
- Neo4j の全文索引は日本語対応（CJKアナライザ）で10本を運用
- Neo4j CE は存在制約を張れないため、スキーマの強制はPydanticエンティティを通す書き込み経路で担保する設計
- マイグレーションはCypherファイル96本。forward-onlyかつ冪等で、デプロイ時に自動適用

### Domain model / Requirement traceability
ノードラベルとリレーション型は列挙型でホワイトリスト化している（ラベル49種以上 / リレーション型74種）。

    Document -[SOURCE_OF]-> DemandDeep(要求カード)
    DemandDeep -[REFINES]-> Requirement            (M:N)
    Requirement -[COVERED_BY]-> UserStory
    UserStory -[HAS_SCENARIO]-> SDLCScenario       (Gherkin)
    UserStory -[HAS_TASK]-> KanbanTask
    SDLCScenario -[IMPLEMENTED_BY]-> KanbanTask
    KanbanTask -[VERIFIED_BY]-> TestResult
    KanbanTask(bug) -[HAS_RESOLUTION]-> BugResolution -[LINKS_CR]-> ChangeRequest
    TranscriptSource -[HAS_CHUNK]-> TranscriptChunk -[MENTIONS]-> Concept

- 要件は 機能 / 非機能 / 制約 の3分類。優先度は MoSCoW（must / should / could / wont）
- 要求カードは6軸で評価する（重要度・インパクト・頻度・利用者受容性・工数・確信度）。人が判断する軸とAIが観測する軸を役割で分けている
- 版管理は SUPERSEDES による Copy-on-Write。過去の版と変更理由が残る
- 受け入れ仕様の正本は Gherkin。EARS記法はPM on Railsには実装していない（BeekleとしてはEARSの解説記事と作成支援ツールを別途公開している）

### Retrieval
- 検索は5系統。Cypherテンプレート / ハイブリッド（ベクトル+全文）/ グラフ拡張（1ホップ）/ GraphRAG / コミュニティ要約によるグローバル検索
- Cypherとハイブリッドを並列実行し、その結果をアンカーにグラフ拡張とGraphRAGを並列実行する
- 統合は RRF（Reciprocal Rank Fusion、k=60）。最終スコアは複数シグナルの重み付き線形結合で、意図分類ごとに重みを差し替える
- 融合後の候補は Cross-Encoder（bge-reranker-v2-m3）で再ランクする
- 埋め込みは OpenAI text-embedding-3-small（1536次元）
- 意図分類（Intent Router）を実装。構造検索・意味検索・ハイブリッド・助言・品質チェック・掘り下げ・直近の懸念・意思決定履歴・議事録参照・全体要約など10種類以上に振り分け、高信頼のキーワードは分類器を通さない速い経路に流す。分類に失敗した場合は必ずハイブリッドにフォールバックする
- コミュニティ検出は Louvain を3階層（解像度を変えて実行）
- 類似要求の検出は3層合成（ベクトル類似度 + 人のフィードバック + グラフ構造の近さ）。重複判定 0.85 / 提案 0.65 を閾値にする
- Cypherテンプレートの実行は常に読み取り専用セッション、タイムアウトと行数上限つき

### AI agent integration (MCP)
- MCPサーバを内蔵する（FastMCP / Streamable HTTP）。公開ツール数151
- 認証は Personal Access Token の Bearer。スコープは25種で、書き込み系は編集者以上の権限を要求する
- トークン発行は RFC 8628 デバイス認可フロー。OAuthのディスカバリ用メタデータを公開する
- npmパッケージ経由で `pm-on-rails mcp install` を実行すると Claude Code に接続でき、stdioとStreamable HTTPを中継する。認証情報はOSキーチェーンに保存
- LLMは OpenRouter 経由で用途別に使い分ける。ワークスペース単位でのキー持ち込みに対応

### Quality gates
- Cypherインジェクション対策は2重。ラベルとリレーション型は列挙型の値しか埋め込まず、列挙化できない識別子は実行時に正規表現で検証する
- マルチテナント分離も2重。プロジェクトにワークスペースIDを持たせたうえでグラフのエッジでも保持し、ID指定でロードした後にワークスペースを再照合する。権限がない場合は403ではなく存在自体を隠す
- ナレッジ（フォルダ・文書・議事録）には閲覧・編集・管理の3種のACLエッジ。フォルダ階層を最大16階層まで遡って継承し、検索結果にもACLの後段フィルタをかける
- DoR / DoD をCypherで自動判定する。要件はストーリーに覆われているか、ストーリーは承認済みシナリオを持ちGherkinが揃っているか、シナリオは最新テスト結果が pass か。未達のタスクは着手をブロックする
- 完了ゲートは Gherkin の SHA-256 ハッシュで証拠の鮮度を判定する。仕様が変わってハッシュがずれたテスト結果は証拠として無効になり、完了できない。判定は 合格 / 不合格 / 証拠不足 / 仕様不整合 の4値
- AIエージェントの reward hacking（都合よくテストを通す振る舞い）を差分から機械検出する。テスト削除・skip追加・xfail追加・シナリオ削除・GherkinのThen削除・アサーション弱体化・アサーション削除の7パターン。安価な決定論的チェックを通してから、LLMによるレビューを行う設計

### Self-application (dogfooding)
PM on Rails 自身の受け入れテストが、PM on Rails のグラフから生成されている。
- グラフ上の SDLCScenario.gherkin を正本とし、リポジトリの .feature はそのスナップショット
- マニフェストがシナリオID・版・GherkinのSHA-256を保持し、テスト実行時にローカルのFeatureとハッシュ照合する
- テストはシナリオIDに紐づくため、「どの受け入れ条件がどのテストで確認されたか」をコードから逆引きできる
- 規模: .feature 225本 / シナリオ 319件 / マニフェスト登録 315件

### Learning loop（不具合から要件へ書き戻す）
1. 不具合をクローズする際に、要件変更が必要かを立てる
2. 影響先を集め、LLMが「新しい要求として起票する」か「既存要件の記述を更新する」かを提案する
3. 提案の段階では永続化しない。人が承認して初めて反映される
4. 解決済みの不具合をベクトル化して蓄積する
5. 新しい要求の類似検索で、過去に不具合履歴を持つ要件を加点する

### Operations
- 非同期処理は arq。定期ジョブ15本（次サイクル自動生成、バックログ腐敗検知、タスク遅延検知、バーンダウン日次スナップショット、上流変更の下流反映、埋め込みカバレッジ修復など）
- 外部連携: GitHub（App/PAT、webhook、Issue・PR・Gherkin同期、PRマージでタスク自動完了）、Slack（Events API / Interactivity / OAuthインストール）、Figma（OAuth PKCE + REST）、Google Cloud Speech-to-Text（話者分離つき）、メール配信、S3互換ストレージ
- CI: 変更パスで backend / frontend / integration / e2e / ADR を出し分ける。統合テストは Testcontainers で実際の Neo4j を起動して実行する。ADRはCIでlintし、ADR変更時に対応するルールファイルが同じPRで更新されているかも検査する
- デプロイ: CI成功をトリガーに、コンテナ更新 → Neo4jマイグレーション → ヘルスチェック

### Scale (2026-08時点、リポジトリ実測)
- バックエンド アプリケーションコード 約172,000行 / Pythonファイル 1,245
- バックエンド テスト関数 7,171（テストファイル918）
- フロントエンド テストケース 985 + E2E 62
- Neo4j リポジトリ実装 92ファイル / Cypherマイグレーション 96
- MCPツール 151 / MCPスコープ 25
- ノードラベル列挙 49種以上 / リレーション型列挙 74種
- ADR: 番号は200番台まで到達。うち115本がリポジトリにmarkdownとして残る（ADRはグラフ上のノードへ移行済み）
- AIエージェント向けルールファイル 134

## Case References

実績は、検証可能な事実（期間・対応範囲・発注者の評価・公開URL）だけを書く。
断定できない部分は Evidence status に明示する。丸めた割合や、測っていない効果は書かない。

### Case: 他社が完成に至らなかった案件の引き継ぎと再構築
- Domain: ヘルスケア／大手企業のDXプロジェクト
- Situation: 先行していた他社ベンダーが約3ヶ月かけても完成に至らず、リリースの目処が立たなかった。
- Initial problems:
  - 仕様が固まりきらないまま実装が進み、手戻りが発生していた
  - リリース時期が見えず、事業計画に影響していた
- Beekle approach:
  - 既存コードと要件を整理し直した
  - バックエンド・フロントエンド・インフラまで一貫して再構築した
  - AIを活用した開発体制で実装を進めた
- Outcome:
  - 引き継ぎから3週間で動作する状態に到達した
  - 発注元の大手企業が外部に委託したセキュリティチェックを、指摘による差し戻しなく一度で通過した
- Evidence status: 期間・対応範囲・セキュリティ審査の通過は確認済み。先行ベンダーが停滞した理由は特定できていないため、原因は主張しない。監査の具体的な項目・スコアは非公開。

### Case: 他社が完成に至らなかった案件の引き継ぎ（進行中）
- Client: 株式会社イデアラボ（掲載許諾済み）
- Project: エスペシャリーミー
- Domain: 業務システム開発
- Situation: 先行していたベンダーが完成に至らず、開発が止まっていた。
- Initial problems:
  - 要件が揃っていなかった
  - 仕様と実装がつながっておらず、何がどこまでできているか確認できなかった
  - 進捗を確からしく把握できなかった
- Beekle approach:
  - 要件を整理し直した
  - 要求をユーザーストーリーと受入条件へ変換した
  - PM on Rails 上で実装を管理した
  - 人が設計とレビューを行ったうえで、AIコーディングエージェントを使った
- Outcome:
  - 要件の再整理を約3日で完了した
  - 最初の2週間サイクルで、開発の約60%が完了した
- Evidence status: 発注元より掲載許諾を得ている。進行中の案件であり、完了実績ではない。数値は現時点の進捗であり、最終結果ではない。顧客へのヒアリングと完了時の結果は、完了後に追記する。

### Case: ヒアリング議事録からRFPを生成し、当日中に動くデモを構築
- Domain: 新規事業・業務システム
- Situation: 構想段階で要件が言語化されておらず、発注側と開発側でイメージのズレが起きやすかった。
- Initial problems:
  - 要件が言語化されておらず、認識のズレが起きやすい
  - 仕様書作成からプロトタイプまでに通常は時間がかかる
- Beekle approach:
  - ヒアリング議事録からRFP（提案依頼書）を生成した
  - RFPをもとに仕様を定義し、仕様駆動開発で実装した
- Outcome:
  - 1日で動作するデモを完成させた
  - 発注者から「イメージとずれていない」と評価された
  - 以降の打ち合わせを、認識合わせではなく中身の検討に使えた
- Evidence status: 期間と発注者の評価は確認済み。デモ開発（仕様駆動開発の実証）であり、本番システムの構築期間ではない。

### Case: Hybrid GraphRAGによるナレッジ検索の構築
- Domain: カスタマーサポート／社内DX
- Situation: 社内に蓄積された資料に対して、根拠を示しながら回答できる検索が必要だった。
- Initial problems:
  - ベクトル検索だけでは、実際のデータ量で精度とスケールに限界があった
  - 回答の根拠を提示できないと、業務判断に使えない
- Beekle approach:
  - メタデータ・全文・ベクトル・グラフ近傍・根拠(Claim)の5経路をRRFで統合した
  - Neo4jでナレッジグラフを構築した
  - 回答後に根拠を検証する工程を入れ、引用元のチャンクを必ず提示する設計にした
  - 資料に無いことは「資料上は確認できません」と返す設計にした
- Outcome:
  - 実データを投入し、VPS上で運用を継続している
- Evidence status: 構成・運用継続は確認済み。精度の定量値は非公開。デモ／PoCとして開始し、その後に実データを追加投入した経緯がある。

### Case: 要件が固まっていない段階から入り、本開発までを担当
- Domain: 介護・ヘルスケア
- Situation: 介護サービスの情報が散らばっており、何をどう作れば高齢の本人や家族が使えるのか、要件が固まっていなかった。
- Initial problems:
  - 高齢者やインターネット初心者にとって使いにくいUIになりやすい
  - 机上の議論では、使えるかどうかを判断できない
- Beekle approach:
  - ヒアリングから「文字入力をなくす」という要件にたどり着いた
  - LINE上でタップするだけのプロトタイプで操作感を確かめてから本開発に進んだ
- Outcome:
  - 本開発 約2ヶ月でリリースした
  - 実サービスとして公開されている（https://iro-ai.com/）
- Evidence status: 期間と公開URLで確認できる。

### Case: PoCから本開発へ接続した心理モデル搭載のHR AIエージェント
- Domain: HR Tech・採用DX
- Situation: 採用と配置の判断が面接担当者の経験や紙の診断票に依存し、候補者と職種、チーム相性を一貫して見る手段がなかった。
- Initial problems:
  - 学術的に正しくても、採用の現場で判断に使えなければ意味がない
  - 何をシステム化し、どこまでを発注範囲にするかが固まっていなかった
- Beekle approach:
  - HEXACO-100の心理尺度をシステム化した
  - LLMを構造化分析のエンジンとして使い、出力をJSON Schemaで固定した
  - 逆転項目・ファセット・ドメイン集計をプロンプト任せにせず実装した
- Outcome:
  - PoC 2週間で作る範囲を確定した
  - 本開発 約3ヶ月で構築した
- Evidence status: 期間と実装方式は確認済み。採用成果への影響は測定していないため主張しない。

### Case: 購買データの分析から顧客データ基盤（CDP）の構築まで
- Domain: toCサブスクリプションサービス
- Situation: サービス本体は稼働していたが、どこを改善すれば課金率が動くかを数字で決められなかった。
- Initial problems:
  - 顧客データが分散していた
  - 優良顧客層を特定できていなかった
- Beekle approach:
  - まずBigQueryで購買データを分析した
  - 最終的な顧客データ基盤（CDP）をDatabricks on AWS上に構築し、アプリDBやGA4を統合した
  - サービス本体を作ったチームがデータ基盤も担当した
- Outcome:
  - 優良顧客層を特定し、LPと課金導線の改善に反映した
- Evidence status: 構成と実施内容は確認済み。改善後の数値は非公開。分析基盤の一部はGit管理外のSaaS上にあり、コードでは追えない。

### Case: RFP作成代行から要件定義・開発・SEOまで一気通貫
- Domain: 製造業・DX
- Situation: 補助金申請の要件としてRFP（提案依頼書）の提出が必要だったが、社内に書ける人がいなかった。
- Initial problems:
  - 発注内容を定義できていなかった
  - 工程ごとに会社が変わると前提の説明をやり直すことになる
- Beekle approach:
  - 要件整理からRFP作成を代行した
  - 要件定義・デザイン・業務(BPO)整理・バックエンド・フロントエンド・SEOまで担当した
- Outcome:
  - 約1年にわたり、発注準備から集客まで同じ体制で担当した
- Evidence status: 対応範囲と期間は確認済み。補助金の採択可否は確認していないため書かない。

### Case: 配信を止めずに実施した商用モバイルアプリの基盤移行
- Domain: モバイルアプリ・大規模toCアプリ
- Situation: リリース済みの商用アプリを、配信を続けたままFlutterへ移行する必要があった。
- Initial problems:
  - 課金・広告・通知といった収益に直結する機能を止められない
  - 設計判断の経緯が残っていないと引き継げない
- Beekle approach:
  - 課金・広告・通知を移行しながら、要件・設計判断・却下理由・受入条件をユースケース単位で記録した
  - 受入条件をE2Eテストへつないだ
- Outcome:
  - 配信を止めずに移行を実施した
  - リリース前の動作確認を自動化した
- Evidence status: 対応範囲は確認済み。移行前後の性能比較は非公開。

## Service Catalog

- /services/management-dx — 経営DX・AI導入支援: 経営課題とデータを整理し、AIレポート、アラート、RAG、AIエージェントの実装まで支援する
- /services/ai-adoption — AI導入支援: 業務選定、評価設計、簡易PoC、データ連携、本番運用、社内定着まで支援する
- /services/web-mobile-development — Web・モバイルアプリ開発: Webアプリ・モバイルアプリの要件整理、プロトタイプ、UI設計、実装、審査・セキュリティ対応まで一貫して進めます。
- /services/cdp-development — CDP構築・顧客データ基盤開発: 散らばった顧客データを統合し、BigQuery × BIで「誰が優良顧客か・次に何を提案すべきか」が見えるCDP（顧客データ基盤）を構築します。
- /services/ai-development — 生成AI受託開発: 社内資料検索、問い合わせ対応、書類処理、定型業務の自動化まで。AI開発の失敗を防ぐ要件定義・評価設計から支援します。
- /services/internal-document-ai-search — 社内文書AI検索システム開発: 社内に眠っているPDF・マニュアル・規程集・過去資料を、AIで検索・根拠付きで回答できる仕組みに変えます。文書投入前の質問設計から支援します。
- /services/rag-system-development — RAGシステム構築: 自社データを活用したRAGシステムを、評価設計から本番運用まで一気通貫で構築します。
- /services/ai-chatbot-development — AIチャットボット開発: 社内FAQ、顧客問い合わせ、ヘルプデスク対応をAIチャットボットで効率化します。回答範囲と有人引き継ぎまで設計します。
- /services/ocr-ai-development — OCR・帳票読み取りAI開発: 紙書類、スキャンPDF、帳票、請求書、申込書などをAIで読み取り、業務で使えるデータに変換します。
- /services/ai-agent-development — AIエージェント開発: 複数のツールやシステムを使う業務タスクを、承認とログを残しながら進めるAIエージェントを設計・実装します。
- /services/requirements-definition-support — 要件定義から伴走するシステム開発: 要件が固まっていない段階から相談できるシステム開発です。会話を要求・受入条件・実装タスクまでつなぐ自社PM基盤「PM on Rails」があるので、要件定義も開発も同じ流れで速く進めます。
- /services/mvp-poc-development — MVP・PoC・プロトタイプ開発: アイデアや新規事業を、大きく作る前に小さく検証するためのMVP・PoC・プロトタイプ開発です。PoC（概念実証）は「実現できるか」を確かめる検証、MVPは「価値があるか」を確かめられる最小限の製品を指します。検証項目の設計から入り、簡易デモや検証用プロトタイプで投資判断の材料を揃えます。
- /services/rfp-creation-support — RFP作成・発注準備支援: システム開発の発注で使うRFP（提案依頼書）の作成を、要件整理から代行・伴走します。書き方がわからない、補助金申請で提出を求められた、という段階から対応します。
- /services/sales-data-coaching — 営業データを営業育成に使える仕組みにする: 架電・商談・受注・失注の記録を一本につなぎ、勝ち負けの理由を担当者ごとに切り出して週次の育成に戻す仕組みを作ります。営業メール生成やリード整理のツールではなく、営業組織がどの段階で数字を落としているかを数字で言える状態にします。
- /services/manufacturing-parts-knowledge-search — 製造業の型番・仕様・適合情報を、探せる知識に変える: 株式会社Beekleは、製造業の部品・型番・適合条件を調べる社内検索システムを受託開発します。PDFの仕様書、Excelの適合表、品目マスタに分かれた情報をつなぎ、回答候補と適用条件、根拠資料の該当箇所を一緒に示します。
- /services/technical-manual-knowledge-search — 自動車・航空の大量マニュアルから、必要な手順と根拠を探せるようにする: 機種・型式・部品・作業条件・文書の版をたどり、適用される手順と根拠箇所を示す技術マニュアル検索を作ります。回答には元文書、該当箇所、文書の版、適用条件を一緒に表示し、最終判断は担当者に残します。
- /services/internal-it-helpdesk-ai — 情シスに何度も来る社内問い合わせを減らす: 社内問い合わせに自動回答するAIを受託開発します。情シス・総務・経理の社内マニュアル・申請ルール・システム情報を参照してAIが一次回答し、権限変更や個別判断が必要なものは担当者へ引き継ぎます。既製のFAQチャットボットを導入するのではなく、自社の例外・権限・既存システムに合わせて個別に作ります。全社の文書を整理してから始める必要はなく、問い合わせの多い一領域から動かします。
- /services/document-processing-automation — 帳票を読むだけで終わらせず、確認・照合・登録まで自動化する: OCRのあとに残る確認、マスタ照合、異常チェック、業務システムへの登録を一つの業務として自動化し、判断が要るものだけ人へ回します。確実に処理できるものは自動で登録し、不明なものだけ人に確認を出す設計です。

## Implementation Stack（実案件で使用）

- Backend: Python/FastAPI, PHP/Laravel, Node.js
- Frontend: TypeScript, React, Next.js, Astro, Inertia.js
- Mobile: Flutter, React Native
- AI/LLM: OpenAI, Anthropic Claude, OpenRouter経由の各種モデル, Cloudflare Workers AI。RAG / GraphRAG / OCR / 音声認識 / レコメンド / マッチングスコアリング
- Data: Neo4j（ナレッジグラフ）, Milvus（ベクトル検索）, PostgreSQL, Redis, BigQuery, Databricks on AWS, GA4
- Infrastructure: AWS（ECS / ALB / WAF）, Cloudflare（Pages / Workers / KV）, Docker, Traefik, Terraform, 自社管理VPS
- Method: 仕様駆動開発, ユーザーストーリー, 受入条件, Gherkin, MCP（Model Context Protocol）連携, Claude Code / Codex などAIエージェントによる実装

## Frequently Asked Questions (technical)

### RAGを作るとき、必ずベクトルデータベースを使いますか？

いいえ。全文検索、ベクトル検索、ハイブリッド検索、ナレッジグラフ、実行時の文書選択の中から、コーパス規模、質問の性質、更新頻度、レイテンシ、精度、運用コストで選びます。より単純な検索方式で評価基準を満たせる場合、ベクトルデータベースは導入しません。

### AIシステムの精度をどう評価しますか？

実際のユーザー質問と業務シナリオから評価データセットを作ります。評価軸は、検索の適合性、回答の正しさ、出典への根拠づけ、引用の正確さ、ハルシネーション率、タスク完了率、レイテンシ、リクエストあたりコスト、人へのエスカレーション率など。評価データセット、閾値、失敗ケース、回帰テストを、可能な限り本番投入の前に定義します。

### ハルシネーションをどう抑えますか？ゼロにできますか？

ゼロにはできません。抑制の手段は、引用元のチャンクを必ず提示する、資料に無いことは「資料上は確認できません」と返す、回答後に根拠を検証する工程を入れる、確信度が低い場合は人へ渡す、といった設計です。加えて、出力に含まれるURLを既知のものだけに制限するなど、プロンプトが破られても捏造が通らない後処理を入れることがあります。

### AIエージェントに実装させると品質が落ちませんか？

曖昧な指示を渡せば、間違った実装が高速に作られます。Beekleは、満たすべき受入条件を機械可読な形にしてから実装させます。加えて、テスト削除、skip追加、アサーションの弱体化といった「都合よくテストを通す」振る舞いを差分から機械検出し、受入条件のハッシュが変わって古くなったテスト結果は完了の証拠として無効にします。実例として、3週間で再構築した案件が、発注元の大手企業による外部セキュリティチェックを一度で通過しています。

### 既存システムの仕様書がありません。刷新できますか？

できます。画面、コード、データ、外部連携、定期処理、実際の運用を確認して、いま本当に使われている仕様を復元します。復元した仕様は資料で終わらせず、そのまま実装と確認へつなぎます。調査を別会社に出して、その成果物を開発会社がもう一度読み直す工程が発生しません。ただし、業務側が現行の運用を説明できず、かつソースコードも提供されない場合は対応できません。

### グラフデータベースの運用は重くないですか？

鮮度管理、品質監視（孤立ノードや重複エンティティの検出）、スキーマの拡張、ロール別のアクセス制御は、VPS構成のままで実装・運用できます。自社の業務システムでこの構成を運用しています。マネージド（Neo4j AuraDBなど）は規模の大小に関わらず運用の手間を減らしますが、従量課金で自前運用より割高になりやすいため、手間とコストのトレードオフで選びます。なお Neo4j Community Edition にはラベル単位のアクセス制御がないため、その分離はアプリケーション層で強制する設計にします。

### 機密情報や個人情報を扱えますか？

NDAの締結に対応します。データを外部に出さない構成（自社管理のVPS上で完結させる構成）の実績があります。マルチテナントの分離は、識別子でのロード後に所属を再検証する二重の防御と、権限がない場合は存在自体を隠す方式で設計します。ナレッジには閲覧・編集・管理のアクセス制御を持たせ、検索結果にも後段でフィルタをかけます。

### 相談の段階で、どこまで費用をかけずに見られますか？

初回相談と、商談時に持参する簡易デモに費用はかかりません。相談内容にもとづいて動くデモを作り、商談の場に持っていきます。資料やスライドではなく実物を見てから、進めるかどうかを判断できます。有償になるのは、実データ連携、個別業務フローへの適合、精度検証、セキュリティ要件を含むPoC以降です。その線引きは、範囲と判断基準を整理したうえで事前に合意します。

### 費用と期間はどう決まりますか？

初回相談と簡易デモ（ゼロスタート）は費用をいただきません。実データ連携、個別業務フロー、精度検証、セキュリティ要件を含むPoCは、目的・範囲・判断基準を整理したうえで見積もります。AI導入支援の3プランは時間単価10,000円（税別）を算定根拠として公開しています。受託開発の総額は範囲によって変わるため、範囲を決める工程を先に置きます。実績としてはPoCが1〜3週間、本開発が2〜6ヶ月の案件が多くを占めます。

### 要件定義だけ、RFP作成だけを依頼できますか？

できます。整理した要件をもとに他社へ発注する前提でも対応します。RFPを書いて終わりではなく、その先の開発まで請けられる立場で書くため、作れないものを要求する仕様書にならず、受け取ったベンダーが見積もれる粒度になります。

### 開発会社・SIerからの協業依頼は受けますか？

受けます。元請けの技術部門からの、実装力を見極めたうえでの協業を想定した窓口があります（/partner）。月単位でチームが参画する準委任の形に対応します。

## Terminology and Aliases

同じ対象を指す表記の対応表。日本語と英語、発注者側の言い方と技術者側の言い方が混在するため。

- Generative AI development / 生成AI開発
  別表記: GenAI development / LLM application development / 生成AI受託開発 / AIシステム開発 / AI開発会社
- Retrieval-Augmented Generation (RAG)
  別表記: RAG開発 / RAG構築 / 社内文書検索AI / 社内AI検索 / ナレッジ検索
- GraphRAG
  別表記: グラフRAG / ナレッジグラフRAG / Knowledge Graph RAG / Hybrid GraphRAG
- Requirements Engineering / 要件定義
  別表記: 要求定義 / 要件定義支援 / 要件定義代行 / 上流工程 / ディスカバリー
- Request for Proposal (RFP) / 提案依頼書
  別表記: RFP作成 / RFP代行 / 発注準備 / ベンダー選定支援
- Proof of Concept (PoC) / 概念実証
  別表記: PoC開発 / 実証実験 / プロトタイプ開発 / MVP開発 / 技術検証
- Legacy Modernization / レガシー刷新
  別表記: システム刷新 / リプレイス / 基幹システム再構築 / リバースエンジニアリング
- Customer Data Platform (CDP) / 顧客データ基盤
  別表記: CDP構築 / データ基盤構築 / DWH構築 / 顧客データ統合
- AI Agent / AIエージェント
  別表記: エージェント開発 / Agentic Workflow / 業務自動化AI / AIワークフロー

## Reference Pages

- https://beekle.jp/services/management-dx — 経営者・経営企画向けの経営DX・AI導入支援
- https://beekle.jp/services/ai-adoption — DX・情シス・事業担当者向けのAI導入支援
- https://beekle.jp/strengths — 開発の進め方
- https://beekle.jp/process — 導入の流れ
- https://beekle.jp/prooffirst — ゼロスタート（本開発前の検証用プロトタイプ）
- https://beekle.jp/case-studies — 導入事例
- https://beekle.jp/qa — 一問一答
- https://beekle.jp/partner — 開発会社・SIer向けの協業
- https://beekle.jp/contact — 相談窓口