CASE STUDY
AIを業務の中核に組み込むと、会社はどう変わるか — 自社開発ツール「projectAI」の全社運用事例
最初に、結論だけ
当社は、受託開発の見積から運用までを一つの画面で管理するプロジェクト管理ツール「projectAI」を自社で開発し、2026年7月から全社で本番運用しています。要点は3つです。
- 30を超えるAI機能とAIエージェント「Mr.AI」が、見積・進行管理・会議・品質管理・多言語対応といった日々の業務の中で動いている
- 業務データを社外のAI事業者に送らない構成を、機能ごとに選べる
- AIにかかる費用と、AIが出す結果の品質を、数字で確かめながら運用している
そして、この基盤と進め方は、お客様の案件でもそのまま使っています。自社で試し、自社で磨いたやり方を、お客様のプロジェクトに持ち込む。それが当社のAI導入支援・システム開発・DX推進支援の土台です。
発注者と同じ悩みから始まった
きっかけは、お客様からよくいただくご相談と同じ悩みでした。いちばんの理由は、コストです。
ツールの費用が、人数とともに積み上がっていた。 当社はプロジェクト管理のために Slack、JIRA、Notion、Google の各サービスを併用しており、従業員40名分のライセンス費用は、各社の公表価格（年払い）で計算すると年間およそ250万円に達していました。人が増えるたびに、使う・使わないにかかわらず席数分の費用が増えていく構造です。
つないでも、できることは限られていた。 各ツールの間でAIやAPIによる連携を組んでいましたが、管理は複雑で、できることには限りがありました。どこかのツールの仕様が変われば連携が止まり、その保守に時間を取られる。連携のための仕組みそのものが、新しい管理対象になっていました。
欲しい機能はなく、使わない機能はたくさんあった。 各ツールにはそれぞれAI機能や共通の機能が次々と追加され、重複する一方で、当社が本当に必要としている機能は見当たりませんでした。たとえば、案件ごとの工数を厳密に追跡し、見積と実績を突き合わせることは、複数のツールをまたぐと非常に複雑な手順になります。受託開発の採算管理に欠かせない機能ほど、汎用ツールの外側にありました。
業務の中核となるデータが、契約先のサービスの中に蓄積されていた。 見積、仕様、タスク、議事録、やり取りが別々の場所に散らばり、全体を見渡すには人の手で集め直す必要がありました。日本とネパールの二拠点では、言葉と時差の壁がそこに重なり、情報のずれを生んでいました。
「DXを提案する会社が、自社では他社のSaaSを使い続けている」。この矛盾を終わらせるため、プロジェクト管理という業務の中核を自分たちの手に取り戻すことにしました。コストも、データも、業務の体験も、自分たちで磨き続けられる状態にすること。それが projectAI の出発点です。
AIが業務のどこで働いているか
projectAI は、プロジェクトマネジメントの国際規格（ISO 21500）とPMBOKに基づいて設計し、要件・機能・タスク・品質（バグとテスト）・変更依頼・議事録・チャット・コスト・お客様との共有までを一つに集約しています。
その中でAIは、一つの大きな仕組みではなく、役割の異なる複数のエージェントの集まりとして動いています。それぞれのエージェントは担当する業務の場面で独立して働き、人が介在しなくても自分の仕事を進めます。そして親にあたる Mr.AI が、プロジェクト全体の記憶を持つ役割を担います。各エージェントが残した記録や結果はプロジェクトの記憶として Mr.AI に集まり、Mr.AI はその文脈をもとに質問に答え、次の場面のエージェントに必要な情報を渡します。なかでも変更依頼の対応は、依頼の登録から仕様の作成、実装、テスト、開発環境での確認、本番環境への反映までを Mr.AI が一貫して進めます。仕様・取り込み・本番反映の各段階で人の承認を挟むことも、承認なしで進める自動モードにすることもできます。
現在動いているAI機能の一覧です（45機能）。
| 担当AI | No. | AI機能 | 役割 |
|---|---|---|---|
| Mr.AI（親・記憶役） | 1 | 社内アシスタント | @メンションで記録をもとに回答 |
| 2 | お客様向けアシスタント | お客様の閲覧範囲内で回答 | |
| 3 | チャットボット | 社内チャット上で回答 | |
| 4 | 記憶の統合 | 毎日、チャットの要点を記憶に | |
| 5 | 不具合の原因分析 | プログラムを調べて原因を投稿 | |
| 変更依頼の自動対応（Mr.AI） | 6 | 仕様の作成 | 仕様と確認手順を作り、承認待ち |
| 7 | 実装 | 仕様どおりにプログラムを変更 | |
| 8 | 自動テスト | 失敗したら直して再試行 | |
| 9 | マージ | 承認後に変更を取り込む | |
| 10 | 開発環境での確認 | 反映して担当者に確認依頼 | |
| 11 | 本番環境への反映 | 本番に反映し、結果を報告 | |
| 12 | 質問と回答 | 迷う点は人に質問 | |
| 13 | 見守り | 停滞を検知して再試行・通知 | |
| 見積・要件整理AI | 14 | 機能の生成 | 仕様書から機能一覧を作る |
| 15 | タスクの生成 | 機能をタスクに分解 | |
| 16 | 案件の要約 | 案件の全体像をまとめる | |
| 進行管理AI | 17 | マイルストーンの生成 | 節目を案として置く |
| 18 | スケジュールの立案 | 日程案を組む | |
| 19 | 依存関係の提案 | 先行タスクを見つける | |
| 20 | 期日の提案 | タスクの期日を案として入れる | |
| 21 | スプリント計画 | 次の期間の組み合わせを提案 | |
| 22 | タスクのレビュー | 粒度や抜けを指摘 | |
| 23 | タスク参照の照合 | 文中の参照を実タスクに結ぶ | |
| 会議AI | 24 | 決定事項の抽出 | 決定・担当・期限を抜き出す |
| 25 | 前回議事録の要約 | 次回冒頭用の要約 | |
| 26 | 共有用の要約 | 関係者向けに言い換えず要約 | |
| 27 | 決定事項のタスク化 | 決まったことをタスクに | |
| 28 | 議事録の翻訳 | 日英で揃える | |
| チャットAI | 29 | メッセージの仕分け | 相談・報告・依頼を分類 |
| 30 | 変更依頼の起票 | やり取りから下書き | |
| 31 | タスクの起票 | やり取りから下書き | |
| 32 | 障害の起票 | 障害報告を検知して下書き | |
| 品質管理AI | 33 | バグ報告の整形 | メモを再現手順つき報告に |
| 34 | バグのタスク化 | 報告を修正タスクに | |
| 35 | 障害のタスク化 | 障害票を対応タスクに | |
| 36 | 類似障害の検索 | 過去の似た障害を提示 | |
| 変更依頼AI | 37 | 変更依頼のレビュー | 不足と影響範囲を指摘 |
| 38 | 変更依頼のタスク化 | 承認済みの変更をタスクに | |
| 39 | 変更内容の要約 | 日英のリリースノート | |
| 多言語AI | 40 | 自動翻訳 | 記録の足りない言語を補う |
| 41 | コンテンツの翻訳 | 構造を保って翻訳 | |
| 42 | 一括翻訳 | 過去の記録をまとめて翻訳 | |
| お客様との共有AI | 43 | 資料の自動仕分け | 案件ごとに振り分け、迷えば人へ |
| お知らせAI | 44 | お知らせの生成 | 反映した変更から利用者向けの文に |
| 45 | 案件の更新履歴 | お客様に見せる変更履歴を作成 |
どの機能にも共通しているのは、AIが「下書き・整理・翻訳・検索」を担い、「決める」のは人だという役割分担です。エージェントは独立して動きますが、勝手に決めることはなく、判断はいつも人の手元に戻ってきます。
なぜ現場に定着したのか
AI導入で最も多い失敗は、「入れたが使われない」ことです。projectAI が全社で使われ続けている理由は、次の3点に集約されます。
AIが拡張し、人が圧縮する。 AIは疲れず、抜けもなく、広い範囲を一気に処理します。一方で、その中から意味を取り出し、決めるのは人です。projectAI のAI機能はすべて、この順番で設計されています。AIが案を広げ、人が判断で絞る。人の判断を省く機能は作っていません。
新しいツールを覚えさせない。 議事録を書けば決定事項が抽出され、チャットに相談を書けば起票の下書きができ、タスクを登録すれば英語版が用意される。AIを「使いに行く」のではなく、いつもの流れの中でAIが動きます。相談したいときは、チャットで Mr.AI に「@」で話しかけるだけです。
勝手に動かない。 Mr.AI はプロジェクトの記録を読み、文脈を理解して答えますが、記録を書き換えることはしません。お客様向けのポータルでは、お客様ごとに有効・無効を選べます。AIが何を根拠に答えたかは記録に残り、あとから確かめられます。
データは外に出さなくていい
AI導入のご相談で必ず出るのが、「業務データを外部のAIに渡していいのか」という懸念です。projectAI では、この問いに構成で答えています。
- AI機能ごとに、クラウドのAIを使うか、自社で運用するローカルLLMを使うかを選べます。切り替えは約30秒で全体に反映され、システムを止める必要はありません
- 社内のAI処理装置は、外へ仕事を取りに行くだけで、外から入ってくる口を持ちません
- ローカルで処理できなかった場合にクラウドへ切り替えた記録は、理由とともにすべて残ります
つまり、第三者のAI事業者へデータを送らない構成を、必要な機能から順に選択できます。データの所在は、自社契約のクラウド環境と自社設備の中に限定されます。最初からすべてをローカルにする必要はなく、扱う情報の機微さに応じて段階的に移していけるのが実務上の利点です。
AIのコストは読める、品質は測れる
「AIを入れたが、月額費用だけが残った」という声も少なくありません。projectAI では、AIの費用と品質を最初から測れるようにしています。
- AIの利用コストを、機能別・案件別に円で可視化しています。ローカルLLMで処理した分は費用ゼロとして記録され、クラウドとローカルの比率も一目で分かります
- 新しくローカルLLMに任せたい機能は、まずクラウドのAIと同じ入力で並走させ、両方の結果を人が比べて判定します。その集計をもとに、任せて良いと判断できた機能から切り替えます
- AIの誤りは仕組みで止めます。決まった形式でしか出力させない、出力を実際のデータと照合して存在しないものは捨てる、気になる出力は記録して後から追える、という三段構えです
AIの効果を「なんとなく便利」で終わらせず、費用と品質を測りながら運用範囲を広げていく。この運用そのものが、お客様にお伝えしているAI導入の進め方です。
貴社の案件では、こう進む
projectAI は当社の社内ツールにとどまりません。お客様の案件は同じ基盤の上で進み、お客様専用のポータルから、進捗・成果物・やり取りをいつでも確認いただけます。議事録やチャットからタスク・課題・決定事項が自動で抽出されるため、「言った・言わない」や記録漏れが起きにくくなります。日本語と英語で同じ画面を見られるので、海外拠点や外国籍のメンバーがいる体制でも情報がずれません。
AI導入をご検討の場合は、次の順で進めます。
- 現状の業務と課題の分析
- 動くAIのデモ — この事例でご紹介した仕組みを、実際の画面でご覧いただきます
- 最初の1エージェントを、貴社の業務で動かす
- 効果を測りながら本番運用へ
- 使いこなす人とエージェントを増やし、内製化へ
進め方と費用のかたちは、AI導入支援のページにまとめています。
数字で見る、開発の速さと規模
以下はすべて、projectAI のソースコード管理の履歴から計測した実数です（2026年3月3日〜8月24日、約6か月・25週間）。
変更の量と速さ
- マージされたプルリクエスト: 993件（週あたり約40件）
- コミット: 2,657件（週あたり約106件、最も多い月は742件）
- 追加した行数: 約44万行、削除した行数: 約11万行（ライブラリの定義ファイル等を除く）
- 現在のソースコード: 約32万行、ファイル数1,500超
品質と運用
- 自動テストのファイル: 237
- リリース: 51回（約6か月で、平均すると週2回）
- 30を超えるAI機能、管理者・開発者・お客様向けの3つの画面、見積から運用までの8つのフェーズを一つの製品に集約
体制
- 東京とカトマンズの開発者10名未満と、AIコーディングエージェント
- 本サイトのお問い合わせ管理・コンテンツ管理も、この基盤の上で運用
この数字は、どのくらいの速さなのか
- 週あたり約40件のプルリクエストは、開発者1人につき、ほぼ営業日ごとに1件の変更がレビューを通ってマージされているペースです。
- リリース週2回は、ソフトウェア開発の生産性調査（DORA）で「週1回から月1回」とされる平均的なチームの帯を上回り、「日次・随時」とされる最上位の帯に近い頻度です。しかも6か月間、途切れずに続いています。
- 約32万行のソースコードを10名未満で6か月というのは、1人あたり月6,000行を超える計算になります。保守や設計を含めた開発者1人の生産量の一般的な目安（月に数百から千数百行）と比べると、桁が一つ違います。
- 見積・仕様・タスク・品質・変更依頼・議事録・チャット・コスト・お客様ポータルまでを備えた業務システムは、通常、専任チームが年単位をかけて作る規模です。それを半年で、しかも自社の全案件で使える状態にしました。
追加した行数の4分の1にあたる約11万行を削除している点は、作りっぱなしにせず、使いながら作り直し続けてきたことを示しています。この速さは、AIコーディングエージェントを前提にした開発プロセスの結果です。どの変更もタスクに紐づけ、紐づかない変更は仕組みで止める。人の判断とAIの実行を分ける運用は、開発の現場でも同じです。
こんな課題をお持ちの方へ
- AIを業務に定着させたい、まず1つの業務から始めたい → AI導入支援
- AIを組み込んだ業務システムやSaaSを構築したい → システム開発
- 組織全体のDXを、自社で回せる形で進めたい → DX推進支援
発注前によくいただく質問
このツールを購入する話ですか。 いいえ。projectAI は当社の業務基盤であり、販売が目的ではありません。この事例でお伝えしたいのは、「AIを業務の中核に組み込み、定着させ、費用と品質を測りながら広げる」という進め方です。貴社の課題に合わせて、同じ進め方で取り組みます。
当社のデータでAIが学習するのですか。 学習には使いません。AIはその場の処理に使うだけで、処理の場所（クラウドか自社設備か）も選べます。
小さな会社や、1つの部門からでも始められますか。 はい。最初の1エージェントを1つの業務で動かし、効果を確かめてから広げるのが基本です。
既存の業務システムとつながりますか。 つながります。新しいツールを覚えていただくのではなく、いま使っている業務の流れの中にAIを組み込む形で設計します。
効果はどう測りますか。 AIの費用を案件別・機能別に可視化し、AIの出力の品質を人が判定する仕組みを、最初から組み込みます。
これからの展開
クライアント案件への標準導入を進めるとともに、ローカルLLMとAIエージェントの内製化を続け、データ・コスト・体験のすべてを自社の管理下に置く開発を続けます。自社の現場で実証した「AIと共に開発するチーム」の知見は、お客様のプロジェクトに、そのまま還元してまいります。