AIを業務の中核に組み込むと、会社はどう変わるか — 自社開発ツール「projectAI」の全社運用事例

最初に

当社は、プロジェクトマネジメントの国際規格（ISO 21500）とPMBOKに基づいて設計した、受託開発の見積から運用までを一つの画面で管理するプロジェクト管理ツール「projectAI」を自社で開発し、2026年7月から全社で本番運用しています。要点は3つです。

• 45のAI機能とAIエージェント「Mr.AI」が、見積・進行管理・会議・品質管理・多言語対応といった日々の業務の中で動いている
• 業務データを社外のAI事業者に送らない構成を、機能ごとに選べる
• AIにかかる費用と、AIが出す結果の品質を、数字で確かめながら運用している

そして、この基盤と進め方は、お客様の案件でもそのまま使っています。自社で試し、自社で磨いたやり方を、お客様のプロジェクトに持ち込む。それが当社のAI導入支援・システム開発・DX推進支援の土台です。

社内とお客様、両方の悩みから始まった

きっかけは、私たち自身が抱えていた悩みでした。そしてそれは、お客様からよくいただくご相談とほとんど同じものでした。いちばんの理由は、コストです。

ツールの費用が、人数とともに積み上がっていた。 当社はプロジェクト管理のために Slack、JIRA、Notion、Google の各サービスを併用していました。従業員40名分となると、ライセンス費用は無視できない金額になります。人が増えるたびに、使う・使わないにかかわらず席数分の費用が増えていく構造です。

つないでも、できることは限られていた。 各ツールの間でAIやAPIによる連携を組んでいましたが、管理は複雑で、できることには限りがありました。どこかのツールの仕様が変われば連携が止まり、その保守に時間を取られる。連携のための仕組みそのものが、新しい管理対象になっていました。

欲しい機能はなく、使わない機能はたくさんあった。 各ツールにはそれぞれAI機能や共通の機能が次々と追加され、重複する一方で、当社が本当に必要としている機能は見当たりませんでした。たとえば、案件ごとの工数を厳密に追跡し、見積と実績を突き合わせることは、複数のツールをまたぐと非常に複雑な手順になります。受託開発の採算管理に欠かせない機能ほど、汎用ツールの外側にありました。

業務の中核となるデータが、契約先のサービスの中に蓄積されていた。 見積、仕様、タスク、議事録、やり取りが別々の場所に散らばり、全体を見渡すには人の手で集め直す必要がありました。日本とネパールの二拠点では、言葉と時差の壁がそこに重なり、情報のずれを生んでいました。

そこで、プロジェクト管理という業務の中核を自分たちの手に取り戻すことにしました。コストも、データも、業務の体験も、自分たちで磨き続けられる状態にする。それが projectAI の出発点です。

AIが業務のどこで働いているか

projectAI は、要件・機能・タスク・品質（バグとテスト）・変更依頼・議事録・チャット・コスト・お客様との共有までを一つに集約しています。

その中でAIは、一つの大きな仕組みではなく、役割の異なる複数のエージェントの集まりとして動いています。それぞれのエージェントは担当する業務の場面で独立して働き、人が介在しなくても自分の仕事を進めます。そして親にあたる Mr.AI が、プロジェクト全体の記憶を持つ役割を担います。各エージェントが残した記録や結果はプロジェクトの記憶として Mr.AI に集まり、Mr.AI はその文脈をもとに質問に答え、次の場面のエージェントに必要な情報を渡します。なかでも変更依頼の対応は、依頼の登録から仕様の作成、実装、テスト、開発環境での確認、本番環境への反映までを Mr.AI が一貫して進めます。仕様・取り込み・本番反映の各段階で人の承認を挟むことも、承認なしで進める自動モードにすることもできます。

下の図は、projectAI が扱っているデータの全体像です。案件・要件・機能・タスク・品質・変更依頼・議事録・チャット・コストといった要素が、線でつながっています。これは開発フェーズの断面で、33の要素が54の線で結ばれ、このフェーズでは18のAI機能が動いています。破線がAIの働く経路です。

拡大すると、要素と要素の間にある「AI」の印が見えます。ここでAIが働いています。たとえばチャットに書かれた不具合はAIが仕分けて起票され、テストケースの失敗は「修正タスク化」を経てタスクとプルリクエストにつながります。

現在動いているAI機能の一覧です（45機能）。

どの機能にも共通しているのは、AIが「下書き・整理・翻訳・検索・反映」を担い、方針を「決める」のは人だという役割分担です。エージェントは24時間独立して動き、何をしたかは記録に残り、影響の大きい段階では人の承認を待ちます。

会社はこう変わった

AI導入で最も多い失敗は、「入れたが使われない」ことです。projectAI が全社で使われ続け、当社の日常はどう変わったのか。要点は4つです。

全自動でも、AI任せでもない。 一つの大きなAIにすべてを任せるのではなく、見積・進行管理・会議・品質・変更依頼・翻訳・お知らせといった各フェーズに、役割の違う複数のAIを分散して組み込みました。AIは疲れず、抜けもなく、広い範囲を一気に処理します。その上で、要所には必ず担当者の判断を入れます。仕様の承認、変更の取り込み、本番への反映、優先順位や工数の決定。AIが案を広げ、担当者が判断で絞る。「AIが拡張し、人が圧縮する」という順番を、機能ごとに守っています。

4つのツールが、1つの画面になった。 Slack、JIRA、Notion、Google に分かれていたプロジェクト管理が一つに集約され、人数分のライセンス費用は不要になりました。代わりに増えたAIの利用料は、機能別・案件別に円で見える費用です。「使っていない席」に払う構造はなくなりました。新しいツールを覚える必要もありません。議事録を書けば決定事項が抽出され、チャットに相談を書けば起票の下書きができ、タスクを登録すれば英語版が用意される。いつもの流れの中でAIが動きます。相談したいときは、チャットで Mr.AI に「@」で話しかけるだけです。

止まらずに動き続け、待ち時間が消えた。 多くのエージェントは、人が指示しなくても24時間動いています。朝には翻訳が揃い、お知らせが作られ、変更依頼の原因の見立てが届き、自動モードなら本番環境への反映まで進んでいます。人がAIを「使う」時間を待たないので、業務が止まりません。東京とカトマンズは同じ画面を同じ言語で見られるようになり、時差は制約ではなくなりました。それでも安心して任せられるのは、AIが何をしたかがすべて記録に残り、影響の大きい段階では人の承認を挟める設計にしているからです。お客様向けのアシスタントは、お客様ごとに有効・無効を選べます。

お客様との関係が、報告から共有に変わった。 お客様専用のポータルで、進捗・成果物・やり取り・変更履歴をそのまま見ていただけます。定例の報告資料を作る代わりに、いつでも同じものを見ながら話ができる。変更依頼は登録から本番反映までの進み具合が可視化され、「今どうなっているか」を尋ねる必要がなくなりました。

データは外に出さなくていい

AI導入のご相談で必ず出るのが、「業務データを外部のAIに渡していいのか」という懸念です。projectAI では、この問いに構成で答えています。

• AI機能ごとに、クラウドのAIを使うか、自社で運用するローカルLLMを使うかを選べます。切り替えは約30秒で全体に反映され、システムを止める必要はありません
• 社内のAI処理装置は、外へ仕事を取りに行くだけで、外から入ってくる口を持ちません
• ローカルで処理できなかった場合にクラウドへ切り替えた記録は、理由とともにすべて残ります

つまり、第三者のAI事業者へデータを送らない構成を、必要な機能から順に選択できます。データの所在は、自社契約のクラウド環境と自社設備の中に限定されます。最初からすべてをローカルにする必要はなく、扱う情報の機微さに応じて段階的に移していけるのが実務上の利点です。

AIのコストは読める、品質は測れる

「AIを入れたが、月額費用だけが残った」という声も少なくありません。projectAI では、AIの費用と品質を最初から測れるようにしています。

• AIの利用コストを、機能別・案件別に円で可視化しています。ローカルLLMで処理した分は費用ゼロとして記録され、クラウドとローカルの比率も一目で分かります
• 新しくローカルLLMに任せたい機能は、まずクラウドのAIと同じ入力で並走させ、両方の結果を人が比べて判定します。その集計をもとに、任せて良いと判断できた機能から切り替えます
• AIの誤りは仕組みで止めます。決まった形式でしか出力させない、出力を実際のデータと照合して存在しないものは捨てる、気になる出力は記録して後から追える、という三段構えです

AIの効果を「なんとなく便利」で終わらせず、費用と品質を測りながら運用範囲を広げていく。この運用そのものが、お客様にお伝えしているAI導入の進め方です。

貴社の案件では、こう進む

projectAI は当社の社内ツールにとどまりません。お客様の案件は同じ基盤の上で進み、お客様専用のポータルから、進捗・成果物・やり取りをいつでも確認いただけます。議事録やチャットからタスク・課題・決定事項が自動で抽出されるため、「言った・言わない」や記録漏れが起きにくくなります。日本語と英語で同じ画面を見られるので、海外拠点や外国籍のメンバーがいる体制でも情報がずれません。

AI導入をご検討の場合は、次の順で進めます。

1. 現状の業務と課題の分析
2. 動くAIのデモ — この事例でご紹介した仕組みを、実際の画面でご覧いただきます
3. 最初の1エージェントを、貴社の業務で動かす
4. 効果を測りながら本番運用へ
5. 使いこなす人とエージェントを増やし、内製化へ

進め方と費用のかたちは、AI導入支援のページにまとめています。

数字で見る、開発の速さと規模

以下はすべて、projectAI のソースコード管理の履歴から計測した実数です（2026年3月3日〜8月24日、約6か月・25週間）。

変更の量と速さ

• マージされたプルリクエスト: 993件（週あたり約40件）
• コミット: 2,657件（週あたり約106件、最も多い月は742件）
• 追加した行数: 約44万行、削除した行数: 約11万行（ライブラリの定義ファイル等を除く）
• 現在のソースコード: 約32万行、ファイル数1,500超

品質と運用

• リリース: 51回（約6か月で、平均すると週2回）
• 45のAI機能、管理者・開発者・お客様向けの3つの画面、見積から運用までの8つのフェーズを一つの製品に集約

この数字は、どのくらいの速さなのか

• 週あたり約40件のプルリクエストは、毎営業日に約8件の変更がレビューを通ってマージされているペースです。
• リリース週2回は、ソフトウェア開発の生産性調査（DORA）で「週1回から月1回」とされる平均的なチームの帯を上回り、「日次・随時」とされる最上位の帯に近い頻度です。しかも6か月間、途切れずに続いています。
• 約32万行のソースコードを6か月で書き上げるのは、保守や設計を含めた開発者1人の生産量の一般的な目安（月に数百から千数百行）から見ると、通常は年単位を要する規模です。
• 見積・仕様・タスク・品質・変更依頼・議事録・チャット・コスト・お客様ポータルまでを備えた業務システムは、通常、専任チームが年単位をかけて作る規模です。それを半年で、しかも自社の全案件で使える状態にしました。

約11万行を削除した、という数字がいちばん重要です。 追加した行数の4分の1にあたる量を、私たちは自分たちで消しています。作って終わりにせず、毎日使いながら PDCA サイクルを回し、使われなかった機能は取り除き、実態に合わなくなった仕様は作り替える。この繰り返しがあったからこそ、半年で「全社の業務に耐える」ものになりました。速く作ることと同じくらい、速く直し、速く捨てることを重視しています。

この速さは、AIコーディングエージェントを前提にした開発プロセスの結果です。どの変更もタスクに紐づけ、紐づかない変更は仕組みで止める。人の判断とAIの実行を分ける運用は、開発の現場でも同じです。

こんな課題をお持ちの方へ

• AIを業務に定着させたい、まず1つの業務から始めたい → AI導入支援
• AIを組み込んだ業務システムやSaaSを構築したい → システム開発
• 組織全体のDXを、自社で回せる形で進めたい → DX推進支援

ご相談の前によくいただく質問

このツールを購入する話ですか。 いいえ。projectAI は当社の業務基盤であり、販売が目的ではありません。この事例でお伝えしたいのは、「AIを業務の中核に組み込み、定着させ、費用と品質を測りながら広げる」という進め方です。貴社の課題に合わせて、同じ進め方で取り組みます。

当社のデータでAIが学習するのですか。 学習には使いません。AIはその場の処理に使うだけで、処理の場所（クラウドか自社設備か）も選べます。

小さな会社や、1つの部門からでも始められますか。 はい。最初の1エージェントを1つの業務で動かし、効果を確かめてから広げるのが基本です。

既存の業務システムとつながりますか。 つながります。新しいツールを覚えていただくのではなく、いま使っている業務の流れの中にAIを組み込む形で設計します。

効果はどう測りますか。 AIの費用を案件別・機能別に可視化し、AIの出力の品質を人が判定する仕組みを、最初から組み込みます。

これからの展開

クライアント案件への標準導入を進めるとともに、ローカルLLMとAIエージェントの内製化を続けます。自社の現場で実証した知見は、お客様のプロジェクトにそのまま還元してまいります。

なぜ、これを自分たちで作ったのか。プロジェクトマネジメントに何を見てきたのか。その背景は、代表の言葉でこちらに書いています。

関連するお知らせ: AIネイティブなプロジェクト管理ツール「projectAI」を自社開発し、全社運用を開始