デジタル化ありきで現場を否定しない。現場の理解から自走までをつなぐ支援。
デジタル化されていないから、遅れている。
紙をなくせば、仕事は効率的になる。
私たちも、かつてはそう考えていました。
しかし、現場の仕事を知るほどに、話はそれほど単純ではないことを思い知らされました。
必要なのは、現場のやり方を頭から否定することではありません。
なぜ、そのやり方が残っているのかを理解し、本当に役立つ仕組みへ変えていくことです。
AI Orchestrationの「End to End コンサルティング」は、現場の理解から企画・実装、そして自分たちで改善を続けられる体制づくりまでを、一つにつなぐ支援です。
現場を否定しない姿勢は、机上の理論ではなく、現場で目の当たりにした事実から生まれました。
「紙を入力フォームに置き換え、業務を効率化しました。」
そのように説明されるシステムの横で、現場の人たちが紙のメモを申し送り、仕事をつないでいる。私たちは、そんな場面を何度も見てきました。
システムが拾いきれず、現場の紙が補っていたもの：
システムが拾いきれなかったものを、現場の工夫が補っていたのです。
そこに残る紙は、単なる「デジタル化の遅れ」ではありませんでした。仕事を成立させるために必要な役割を担っていました。
もちろん、紙を残すことが目的ではありません。
ただ、その役割を理解しないまま紙だけをなくしても、問題を解決したことにはなりません。
私たちは、紙をなくす前に、紙が担っている仕事を見に行きます。
導入それ自体ではなく、「仕事が実際にどう変わったか」を唯一の判断基準にします。
入力画面ができた。情報がデータベースに入った。
それだけで、業務が改善されたと言えるでしょうか。
入力にかかる時間は減ったか。確認や転記の手間は増えていないか。
例外が起きたとき、誰かが見えないところで負担を引き受けていないか。
導入費用だけでなく、日々の運用や改修にかかる負担まで含めて、価値が生まれているか。
私たちが確かめたいのは、デジタル化した範囲ではなく、仕事が実際にどう変わったかです。
そのために、何を改善するのか、何をもって改善したと判断するのかを、支援の初めに共有します。そして、実際の業務で確かめ、期待した変化が得られなければ、設計から見直します。
現場のやり方を、そのまま固定するのでもない。
現場を、システムの都合に押し込めるのでもない。
事業の目的に照らして、業務と仕組みの両方を見直す。
それが、私たちの出発点です。
現場理解、企画、実装の分断を解消し、AIを現場との改善を前に進めるために使います。
現場で聞いた課題が、企画書になり、仕様書になり、開発担当者へ渡されていく。その過程で、最初に解決したかった問題が、少しずつ違うものになってしまう。
私たちは、この分断を小さくしたいと考えています。
現場の仕事を理解し、解決策を考え、実際につくり、使ってもらう。そこで分かったことを、次の改善に反映する。
この一連の流れを、切り離さずに進めます。
海外で実践されてきたFDE（Forward Deployed Engineer）も、技術者が顧客の現場に深く関わり、課題の理解から設計・実装までを担うアプローチです。
私たちも、こうした現場と実装をつなぐ考え方を重視しています。そしてAIを、調査や試作、実装・検証を支え、現場の人たちと改善を進めるために活用します。
ただし、外部の専門家が改善を担い続けることを、最終的な姿にはしません。
その力を、どうすれば顧客の組織に残せるか。
そこまでを、支援の中に組み込みます。
End to End コンサルティングは、開発支援と人材育成を別々に行うサービスではありません。
実際の業務課題を題材に、社員の方々と一緒にシステムをつくり、その過程で、自分たちで改善する力を育てていきます。
最初に整理するのは、解決したい課題と、社内で担えるようになりたい範囲です。そのうえで、社員の方々の経験や役割に合わせ、開発計画と教育計画を一体で設計します。
課題の分解からAIを活用したプロトタイプ実装まで、実際に動作する形をスピーディーにお見せし、実現への道筋と基準を共有します。
実務課題を題材に、社員の方とともにプロンプトの調整や機能の試作、修正作業を並走して行い、実装の感覚を掴んでいただきます。
現場主導で改善・改修を行い、技術的な安全性や保守性のレビューを私たちがバックアップ。自走できる状態へ段階的に移行します。
理解と習熟に合わせて、少しずつ役割を移していきます。
学ぶのは、AIへの指示の出し方だけではありません。課題を分解し、必要な情報を調べ、試し、結果を確かめ、うまくいかなければ原因を探して修正する。その問題解決の進め方を、実務の中で身につけていきます。
もちろん、通常業務を抱える社員の方に、開発まで丸投げすることではありません。担当者、学習に使える時間、変更できる範囲、専門家が確認する部分を、経営層とともに整えます。
システムができるだけでなく、それを理解し、変えていける人と仕組みが社内に残る。
それが、私たちの目指す支援です。
外部の専門家への永続的な依存ではなく、自社で改善の主導権を握り続ける状態をゴールとします。
業務が変わったとき、自分たちで変更点を整理できる。
必要な範囲では、AIを使ってシステムを改修し、動作を確かめられる。
専門的な対応が必要なときには、何を相談し、何を任せるべきか判断できる。
私たちが目指すのは、そのような会社です。
すべての社員をエンジニアにする必要はありません。
すべてのシステムを、自社だけで開発・保守する必要もありません。
大切なのは、自社で改善できる範囲と、専門家に任せる範囲を理解し、改善の主導権を自社で持つことです。
また、外部の専門家への依存を、社内の一人への依存に置き換えるだけでは十分ではありません。変更の理由や確認手順を共有し、担当者が変わっても引き継げる状態を目指します。
私たちは、必要なときに相談できる専門家であり続けたい。
しかし、私たちがいなければ何も変えられない状態を、つくりたいわけではありません。
変化のたびに外部へ依頼する会社から、
AIを使って、自ら変化に対応できる会社へ。
これが、AI Orchestrationの「End to End コンサルティング」の思想です。
私たちは、助言だけを提供する会社ではありません。
自らプロダクトを開発・運用する実践と、顧客の事業・開発に関わる経験を、支援に生かします。
既存のデマンドコントローラー、EMS、蓄電池、空調が独立制御。通信仕様や遅延、書き込み競合など、現場特有の制約。
事業価値から開発要件へ変換。責任分界と運用条件を整理し、30分電力量予算とEWMA予測充放電制御ロジックを設計・実装。
実設備での通信制御経路・充放電動作を確認。シャドーモードによる予測制御・精度評価機能を実装し、現在も継続評価中。
自治体ごとに形式が異なる膨大な公的支援データ、自然言語での曖昧な検索要求、LLMのトークン制約とAPI応答速度の壁。
データ収集・正規化パイプラインを構築し、LLMと外部データベースを安全かつ高速に連携するオーケストレーションアーキテクチャを実装。
国内初の公的支援検索プラグインとして公開・商用運用。実際の利用者行動とログ分析に基づき、継続的な改善を実施。
地方都市での分散型データセンター誘致に伴う、電力供給、通信インフラ、災害リスク、採算性といった多面的な前提条件。
抽象的な誘致構想から、地域性・技術的制約・運用コストを突き合わせた実現可能性の評価基準と設計シナリオを具体化。
技術・事業両面でのフィジビリティスタディを完了。意思決定に必要な客観的判断材料を整理。