Reports - Valtes Innovations

AIエージェント、生成AIと何が違うのか　日本企業3社に学ぶ「ケンタウロス型」の始め方

細野淳一 — Mon, 22 Jun 2026 10:19:59 +0000

「生成AIを導入したものの、業務に本格的に組み込む次の一手が見えない」。そうした声が、DX推進の現場で広がっています。

AIエージェント（AI agent）と聞くと、すべてをAIが全自動でこなすイメージを持つ方も多いかもしれません。しかし、日本の先行企業が実際に採っているのは、人間が戦略・判断を握り、AIが定型タスクを担う分業モデルです。この記事では、その分業モデルの設計原則を、サイバーエージェント・パナソニックコネクト・三菱UFJ銀行の事例から読み解き、自社での始め方の考え方を整理します。

「AIエージェント」とは何か、生成AIとの3つの違い

生成AIは「聞けば答える道具」、エージェントは「頼めば動く担当者」

生成AI（generative AI）は、人間が質問や指示を入力するたびにテキストや画像を生成する道具です。指示のたびに人間が介在する点が特徴で、AIは受け身で応答します。

これに対してAIエージェントは、与えられた目標に向けて複数のステップを自律的に実行します。「このデータを整理してレポートを作り、担当者にSlackで通知する」という一連の業務を、人間が途中で操作しなくても実行できる点が生成AIとの最大の違いです。2つの違いを並べると、以下のとおりです。

観点	生成AI	AIエージェント
実行の自律性	1回の入力に対して1回応答。人間が毎回介在する	複数のツールやシステムを連携させながら多段のタスクを自律実行
記憶・継続性	原則として各会話は独立。前の処理を引き継がない	過去の処理結果を記憶・参照しながら次のアクションを判断できる
実行範囲	テキスト・画像の生成が主	情報収集・文書生成・外部システムへの書き込みを一連のワークフローとしてこなす

人間とAIの分業パターン、3つの類型

Harvard Business School などの研究（Fortune誌 2026年1月）は、人間とAIの協働スタイルを3つの類型に整理しています。

類型	人間の役割	AIの役割	代表的な用途
サイボーグ（Cyborg）型	操作・判断・出力整形	リアルタイム補完・提案	コーディング補助、文書の下書き
ケンタウロス（Centaur）型	戦略・難しい判断・例外処理	定型タスクの反復実行・情報収集	ヘルプデスク対応、制作支援
セルフ・オートメーター（Self-Automator）型	パイプライン設計・ルール定義	エンドツーエンドの自律実行	バッチ処理、単純チケット対応

この中でも「ケンタウロス型」という呼び名は、半人半馬の神話的存在に由来します。人間の知性とAIの処理能力が一体となった存在を指し、自社で実践できる分業モデルの核心を端的に表す比喩です。

現在最も普及しているのはケンタウロス型

上記の研究は、現在最も普及している協働スタイルはケンタウロス型だと指摘しています。また Stanford Digital Economy Lab は2025年に「Centaur Evaluations（人間とAIの協働チームとしての評価基準）」を公開し、人間とAIの協働効果を測る枠組みが研究・実務の両面で広がり始めました。「AIに何でも任せる」のではなく「AIが得意な部分だけを委任する」設計が、業務での現実解として定着しつつあります。

「丸ごと自動化」が難しい理由と、ケンタウロス型が選ばれる根拠

全自動が難しい3つの壁

AIに業務を全自動でやらせたいという期待は自然ですが、現状では多くの業務で越えにくい壁が3つあります。

1つ目は例外処理です。業務の大部分は定型手順で進みますが、データの欠落・顧客からの特殊要望・規制上のグレーゾーンへの対応は、依然として人間の判断が不可欠な領域です。2つ目は責任の所在で、稟議書の承認・融資の判断・法律上の決定など「誰がどう決めたか」を問われる場面では、AIが最終判断を代替できる状態にまだ至っていません。3つ目が信頼性の担保です。AIの出力が正しいかを確認する仕組みなしに全自動化すると、誤った情報がそのまま業務に流れ込むリスクを制御できなくなります。

人間の役割を「決める人」に絞り込む設計

ケンタウロス型の核心は、人間の役割を「決める人」に絞り込むことにあります。情報収集・下書き作成・定型確認といった、判断以前の作業をAIが担います。人間は判断・承認・例外対応に集中します。AIを投入しつつ責任と品質保証の仕組みを維持できるのは、この分業の設計があるからです。

人は例外時だけ対応する運用へ

この分業を実装するスタイルとして広まっているのが、Human-on-the-Loop（HOTL、人間は例外時だけ介入する運用）です。AIが自律的に実行し、人間はエラーや例外が発生したときだけ介入します。欧米のヘルプデスクでは、この設計でTier-1（一次対応）チケットの自律解決率が40〜65%に達するという実績もあり、ケンタウロス型の有効性を裏づけています。

AIへの委任範囲を業務特性に合わせて設計することが成果を出す鍵です。HOTLは2025〜2026年の業務AI設計の主流として位置づけられています。ここからは、日本企業3社がどのように分業を設計し、どんな成果を出したかを具体的に見ていきます。

サイバーエージェント・パナソニックコネクト・三菱UFJ銀行、3社の役割分担と効果

広告クリエイティブ×制作量4.5倍、サイバーエージェント「極予測AI」

サイバーエージェントは、インターネット広告のクリエイティブ制作部門に「極予測AI」を展開しています。2020年ごろにサービスを開始し、2024年時点で500アカウント超に導入されています。

この仕組みでAIが担うのは、効果スコアの算出と素材生成です。現在配信中の最高効果クリエイティブと新規案を比較して「勝てる見込みがあるもの」だけを選別し、広告主との確認フローをSlack連携で自動処理します。一方、人間（クリエイター）が担うのは企画立案・制作・広告主との折衝・最終判断です。AIはあくまで「羅針盤と素材を提供する」役割であり、クリエイターがその情報を使って制作するという分業体制を明確にしています。

この設計の結果、クリエイター1人あたりの制作量は約4.5倍に拡大し、通常プロセス比での勝率は2.6倍に達しました。また「極予測やりとりAI」の導入によって、広告主確認にかかる期間が従来の平均8営業日から最短1日に短縮されています。

この事例で注目すべき点は、AIスコアの「盲信リスク」への対処です。スコアが高くても企画の独自性が失われるケースが生じたため、「極多様性プロット」というツールを別途導入し、表現の偏りを可視化してクリエイターが主体的に未開拓領域を探れる設計に改めました。AIを「答えを出す機械」ではなく「視野を広げるツール」として位置づけ直したことが、人間とAIの分業バランスを維持できた要因です。

全社展開×年間44.8万時間削減、パナソニックコネクト「ConnectAI」

パナソニックコネクトは、社員約11,600人を対象に「ConnectAI」を2023年度から導入し、2024年度には年間44.8万時間の業務削減を達成しました。導入1年目（2023年度）の18.6万時間から前年比2.4倍という伸びが、継続改善の証拠として公式発表で示されています。

現在の活用状況を見ると、品質管理では規定630件・11,743ページから根拠を照合してAIが回答し、人間は判断と最終確認を担います。法務では下請法チェックの条文照合をAIが実行し、IT・開発支援ではコード全体の生成とリファクタリング案の提示をAIが行います。月間ユニークユーザー率は49.1%に達しており、1回あたり平均28分の削減が確認されています。

この事例が「段階設計」の好例として特に参考になるのは、パナソニックコネクト自身が社内の変化を「オラクル型→ジーニー型→ソブリン型」という3段階で定義している点です。導入初期の「おすすめは？」という検索エンジン的な使い方（オラクル型）から、資料レビューや複合タスクを依頼する形（ジーニー型）へ進化し、目標として自律的に計画・実行・確認まで行う完全エージェント型（ソブリン型）の移行を計画しています。現在は主にジーニー型で稼働しており、一部業務でソブリン型への移行が始まっています。

導入初期には、社員が単純な事実確認にしかAIを使わないという課題が生じました。これに対し、利用段階のフレームを明示して活用事例の社内共有を強化したことで、使い方文化の浸透に成功しています。

融資稟議書ドラフト×実証段階、三菱UFJ銀行×Sakana AI

三菱UFJ銀行は、生成AIスタートアップ Sakana AI と共同で融資稟議書AIエージェントの実証実験を行いました。法人融資業務の営業担当・審査担当を対象に総勢約100名（コアメンバー約30名）が参加し、2026年4月以降に一部営業店・部門から段階的な実案件での検証を開始すると発表されています。

分業の設計は明確です。従来は「初期情報収集→財務分析→リスク評価→稟議書作成」のすべてを行員が担っていましたが、AIエージェントが企業情報・財務データの収集と整理、財務シミュレーション、稟議書のドラフト作成を担います。行員はAIドラフトの確認・修正と最終的な融資判断を担い、顧客との関係構築・折衝はAIが代替しない領域として明示されています。

この事例の定量的な効果については、実証段階であり現時点では数値が公表されていません。Sakana AI 公式ブログには、若手から熟練行員まで幅広い経験層のスキルギャップを補完できること、稟議書作成の初期段階における作業時間の短縮が期待されることが記されていますが、削減時間・精度などの具体的な数値は段階展開後に明らかになる見込みです。

この事例で注目すべき点は、「汎用AI」ではなく「融資業務特化型エージェント」として設計した点です。三菱UFJ銀行の行員と Sakana AI のエンジニアが密に協働し、融資審査基準・コンプライアンス要件・金融規制という専門知識をAIに組み込む作業に相当な工数を割いています。金融業界という高い精度が求められる領域でも、人間が最終判断を握りAIが情報整理とドラフト作成を担うというケンタウロス型の設計原則が、実装可能であることを示した事例です。

3社の事例を、自社の業務に置き換えるとどうなるでしょうか。「どの業務からAIに任せられるか」を具体的に検討するための事例集をご用意しています。

無料DL: AI導入50事例からみる業務部門のAI活用ガイド

自社の業務から始める3つの判断軸

3社の事例に共通する成功要因を横断して見ると、自社での始め方を考えるうえで参考になる観点が浮かび上がります。

AIに委任しやすい業務の特徴

3社のいずれも、AIに任せるタスクを「情報整理・下書き作成・定型確認」の3種類に絞り込んでいます。ではなぜこの3種類から始めるのでしょうか。共通するのは、入力と出力の形が定まっており、処理の正誤を人間が確認しやすいという特徴です。パナソニックコネクトの品質管理規定照合も、サイバーエージェントのクリエイティブスコア算出も、三菱UFJの稟議書ドラフト作成も、この特徴を満たしています。逆に言えば、人間の経験と暗黙知が必要な判断の場面や、ミスが取り返しのつかない影響を生む処理は、まだAIへの委任に向いていません。

AIに委任する範囲と人間が握る役割の切り分け

ケンタウロス型を設計するうえで最初に合意しておくべきは、「どんな状況で人間が判断するか」というエスカレーション条件です。これが曖昧なまま自律化を進めると、AIが想定外の出力を続けても誰も気づかない、あるいは逆に人間が必要以上に介入して効率が出ないという状況に陥りやすくなります。

Observe（観察）から始めることも有効です。いきなりAIに自律実行させるのではなく、まずAIの処理内容を人間が横に立ってログとして確認する期間を設けてから委任範囲を広げていく方法は、3社の移行パターンと一致しています。

チャット型から試してエージェント型へ移行する段階設計

3社はいずれも「チャット型から始めてエージェント型に段階移行」しています。パナソニックコネクトの「オラクル→ジーニー→ソブリン」というフレームはその意図を最も明示した例ですが、サイバーエージェントも三菱UFJも、試験期間を経てから実運用に移すという同じ設計を採っています。全社一斉展開ではなく、限られた業務・部門から始めて効果を計測し、再現性を確認してから横展開する進め方が、業種や規模を問わず再現できる設計原則です。

効果を時間削減で定量化して継続改善のサイクルを回すことも、3社の共通パターンです。パナソニックコネクトが年次で削減時間を公表し続けているのは、単なる広報活動ではなく、社内推進の根拠を数字で積み上げる仕組みとして機能しています。

人が判断を握り、AIが実行を担う

3社の事例が示すのは、「AIをどれだけ賢くするか」ではなく「人間の役割をどう設計するか」が成果を分けるという事実です。情報整理・下書き・定型実行をAIに任せ、判断・承認・例外対応を人間が握るケンタウロス型は、チャット型からの自然な移行として業種や規模に関係なく実装できる設計原則です。

バルテス・イノベーションズも、この「人が判断し、AIが定型を担う」分業を業種をまたいで実装してきました。営業部門では、商談後の議事録作成・SFA入力・提案書ドラフトをAIが生成し、トップ営業の判断パターンをRAG（社内の知識を検索して回答に使う仕組み）で組織の資産に変えています。医療の現場では、音声記録から電子カルテへの連携をAIが担い、承認者のログで人による最終確認を残しています。システム保守の領域では、COBOLからJavaへの変換を90%以上自動化し、従来は手作業で10名×6か月を要した移行を2名×8か月で完了した実績もあります。このほか製造業の設計・検品、多拠点の受付・入館統制など、対応領域はAIソリューションのページで紹介しています。

一方で、自社のどの業務から始めるか、どこまでAIに委任し、どこで人間が判断を握るかの設計は、簡単ではありません。どこから委任すれば効果が出るか、エスカレーション条件（AIが人間に判断を戻す境界）をどう設計するかは、業務を知らなければ決められず、実装経験がなければ試行錯誤のコストが積み上がります。

人とAIの役割をどう分けるか、自社の業務に当てはめて整理するところから始めてみてください。業務部門での進め方は、事例から逆算すると見えてきます。

無料DL: AI導入50事例からみる業務部門のAI活用ガイド

自社での委任範囲の設計・実装から相談したい場合は、無料相談もご利用いただけます（ご相談・デモ・お見積もり依頼を受け付けています）。

参考出典

ログミーBusiness 技育祭2024講演レポート（登壇者: 毛利真崇氏）https://logmi.jp/main/technology/330700
サイバーエージェント公式プレスリリース（極予測やりとりAI）https://www.cyberagent.co.jp/news/detail/id=29953
サイバーエージェント公式プレスリリース（極多様性プロット）https://www.cyberagent.co.jp/news/detail/id=32243
パナソニックニュースルーム公式プレスリリース（2025年7月7日・44.8万時間）https://news.panasonic.com/jp/press/jn250707-2
パナソニックニュースルーム公式プレスリリース（2024年6月25日・18.6万時間）https://news.panasonic.com/jp/press/jn240625-1
Sakana AI 公式ブログ（三菱UFJ銀行融資稟議AIエージェント）https://sakana.ai/mufg-ai-lending/
Harvard Business School / Fortune誌（2026年1月）AIエージェント3類型
Stanford Digital Economy Lab「Centaur Evaluations」（2025年）

The post AIエージェント、生成AIと何が違うのか　日本企業3社に学ぶ「ケンタウロス型」の始め方 first appeared on Valtes Innovations.

生成AIの料金が定額から従量へ、2026年4〜6月の経緯を年表で整理【2026年6月時点】

細野淳一 — Mon, 15 Jun 2026 02:34:53 +0000

「Copilotは値上げされるのか」「Claudeの料金も上がるのか」。2026年春から相次ぐ生成AIサービスの発表を、値上げのニュースとして受け取った方は多いはずです。しかし、起きているのは単純な値上げではありません。定額使い放題のモデルが先に行き詰まり、課金の構造そのものが「使った分だけ払う」従量へ移る転換です。本記事では、2026年4月から6月の経緯を年表で整理し、各社が一斉に動いた背景と、新最上位モデル「Claude Fable 5」の価格が示す方向を解説します。記述は2026年6月時点の公開情報に基づきます。

4月の決壊点、6月の答え合わせ

流れは3行で

2026年4月、GitHubはCopilot個人向け有償プランの新規販売を停止しました。市場リーダーが製品の新規販売を止めるほど、定額使い放題の前提が行き詰まっていたわけです。ここが決壊点でした。6月に入ると、GitHub・Anthropic・Googleが約1か月のうちに相次いで従量制・クレジット制への移行を打ち出します。いわば答え合わせです。3陣営がほぼ同時期に同じ方向へ動いた事実は、個社の値上げではなく課金構造そのものの転換を示している、と見るのが妥当でしょう。

詳細年表

時期	出来事
4月10日	GitHub Copilot: 新規無料トライアルを停止。理由は「不正利用の急増」と報じられている
4月20日	GitHub Copilot: 個人向け有償プラン（Pro/Pro+/Student。公式FAQではMaxも対象と案内）の新規契約を停止。「エージェント型ワークフローが計算需要の前提を根本から変えた」と公式に説明。2026年6月時点でも再開は未定
5月中旬	Anthropic: 自動実行系（Agent SDK・`claude -p`など）をサブスク枠から分離しクレジット制へ移行すると発表（発効は6月15日）
6月1日	GitHub Copilot: 「プレミアムリクエスト」制を廃止し、GitHub AI Creditsによる従量制へ移行。1クレジット＝$0.01。コード補完・NES（次の編集箇所の自動提案）は消費対象外、月額基本料は据え置き
6月9日	Anthropic: 新最上位モデル「Claude Fable 5」提供開始。プラン内の扱いは後述
6月15日	Anthropic: 自動実行系のクレジット分離が発効（予定・告知済み）
6月18日	Google: Gemini CLIの提供終了、Antigravity CLIへ吸収（予定・告知済み）。無料枠は約1,000リクエスト/日から縮小。公式は週次のコンピュート上限を示し、コミュニティ報告では約20リクエスト/日相当。企業向けGemini Code Assist Standard/Enterprise契約は従来アクセス維持

値上げが先ではなく、定額モデルが先に行き詰まった。この順序が今回の変化の性質を物語っています。

人間がチャットで使う前提だった定額制

ここからは背景の解釈です。定額制はもともと「人間がチャットで使う」ことを前提に設計されていました。人間は1日に数十回しかAIに質問しませんが、AIエージェント（指示を受けて複数の手順を自律的に進めるAI）は1つのタスクでAIを数百〜数千回呼び出すことがあり、24時間動き続けられます。前提が変われば課金も変わる。その結果、業界の線引きは「人間の対話は定額、機械の自動実行は従量、最高性能はプレミアム価格」へ収斂しつつあると見られます。電気やクラウドが「使った分だけ払う」方式で業務インフラとして定着したのと同じ道筋で、生成AIが試すものから業務インフラになったことの裏返しともいえます。

Fable 5の価格が示す知能の価格分化

2026年6月9日に提供が始まった新最上位モデル「Claude Fable 5」のAPI価格は、公式発表によると入力$10/出力$50（100万トークンあたり）です。従来の最上位だったOpus 4.8の単価$5/$25と並べるとちょうど2倍にあたります。ただし公式発表に「従来比2倍」という直接の比較が書かれているわけではなく、単価の並びから読み取れる関係です。最高性能のモデルには相応の価格が付く。「知能の価格分化」が価格表の上で明確になったと見ることができます。なお、Fable 5のプラン内での扱いは、2026年6月時点では「6月22日までプラン内無料、6月23日以降はクレジット必須、容量確保後にプランへ復帰予定」とされ、本記事の中で最も変わりやすい部分です。利用時には、Anthropic公式サポートページの最新案内が判断の正本になります。

6月15日以降に控える3つの変更

2026年6月時点で告知されている直近の予定は3つです。6月15日にAnthropicの自動実行系クレジット分離が発効し、6月18日にGemini CLIが提供を終了、6月23日からはFable 5の対話利用もクレジット必須に切り替わります。一方で、GitHub Copilot個人向け有償プランの新規受付再開は未定のままです。価格・仕様は生成AI領域で最も動きの速い部分のため、適用時には各社公式の最新案内が判断の正本になります。

変わったのは構造、問われるのは自社の対応

ここまでの経緯が示すとおり、変わったのは個社の価格表ではなく課金の構造です。一方で、実務で問われるのは「自社のどの自動化が課金対象になるか」の切り分けと、その後の管理の手順です。定額のまま使える範囲と直撃する自動化の判定表、使用量のモニタリング・モデル使い分け・ROI（投資対効果）管理というコスト管理3ステップは、実務ガイド記事で解説しています。

部門別のAI活用事例から導入効果の相場観をつかみたい場合は、11カテゴリ・50事例をまとめた資料もご利用いただけます。

無料DL: AI導入50事例からみる業務部門のAI活用ガイド

The post 生成AIの料金が定額から従量へ、2026年4〜6月の経緯を年表で整理【2026年6月時点】 first appeared on Valtes Innovations.

Claudeの従量課金移行で生成AIの料金はどう変わるか——「直撃する自動化」の切り分けとコスト管理3ステップ【2026年6月時点】

細野淳一 — Mon, 15 Jun 2026 02:35:01 +0000

「Copilotのプランが変わる」「Claudeの自動実行はクレジット制になる」。この春から、生成AIサービスの変更通知が立て続けに届いています。通知の文面は各社各様ですが、気になることは一つのはずです。自分の部門で動かしているあの自動化は、課金の対象になるのか。

線引き自体は単純です。人が対話で使う分はこれまでどおり定額のまま、機械が自動実行する分は使った量に応じて支払う従量へ。各社の変更はこの一点に収斂しています。難しいのは、自社のどのジョブが「機械の自動実行」に当たるかの見極めです。

本記事では、自社の自動化が従量課金の対象かを判定する切り分け方、2026年4月から6月の経緯の要点、そして月曜から始められるコスト管理3ステップを解説します。記述は2026年6月時点の公開情報に基づきます。

定額のまま使える利用、従量に変わる自動化

人の対話は定額のまま、機械の自動実行は従量へ

今回の変化の構造を最もはっきり示すのが、Anthropic（Claudeの提供元）が2026年6月15日に発効を予定している変更です。公式の説明によると、人が画面に向かって対話しながら使うClaudeアプリとClaude Codeは、これまでどおり月額プランの枠内に残ります。分離されるのは、プログラムがAIを自動で呼び出す形態です。Agent SDK経由の実行、claude -pコマンドによる実行、GitHub Actionsからの呼び出し、サードパーティ製ツールからの認証利用。この4つが月額プランの枠外となり、専用のクレジット制に移ります。

クレジットはプランに応じて月次で付与されます。Pro（月額$20）・Max 5x（同$100）・Max 20x（同$200）の各プランに割り当てられ、API単価で消費されます。繰り越しはありません。使い切り・翌月リセットの方式です。しかも自動では有効にならず、利用者がclaim（受け取り）の操作をして初めて使えるオプトイン方式です。クレジット仕様は変動が大きいため、本段落の数字は2026年6月時点のものです。

無風・クレジット消費・直撃の3分類

自社の、あるいは自分の使い方は、次の3つのいずれかに当てはまります。社内にそのまま持ち帰れるよう、注記まで表に収めています。

分類	従量課金移行の影響	該当する利用例
① チャット利用のみ（人がその都度指示する）	無風。定額プランのまま使える	ブラウザ・アプリでの質問、文章作成、資料の要約
② 上位モデルの多用（人の対話だが最上位モデル中心）	クレジット消費。月額基本料に加え、上位モデルの利用分がクレジットを消費	コーディング支援で最上位モデルを常用、最新最上位モデルでの長文処理（Fable 5の対話利用は6月23日以降ここに該当）
③ 定額サブスク枠内の自動実行	直撃。定額枠から分離され、従量（クレジット）払いに	毎朝のレポート自動生成、定時バッチ処理、コードの自動レビュー

※生成AIの課金変更（GitHub・Anthropic・Google）に関する2026年6月時点の公開情報に基づく整理。
※②の例外: 最新最上位モデル（Fable 5）は対話利用でも2026年6月23日以降クレジット必須。

読み進めるための用語4つ

トークンは、AIが文章を処理する単位です。日本語ではおおむね1文字＝1〜2トークンが目安で、この記事1本（約4,500字）なら1万トークン弱に相当します。
Agent SDK、ヘッドレス実行、claude -pは、いずれも「コマンドでAIを自動実行する形態」を指します。毎朝のレポート自動生成、問い合わせメールの自動仕分け、コード変更の自動レビューが業務での代表例です。
AIエージェントは、指示を受けて複数の手順を自律的に進めるAIです。1つのタスクでAIを数百〜数千回呼び出すことがあり、1日数十回の人の対話とは桁が違います。従量課金で効いてくるのはこの桁です。
「サブスク枠から分離」は、月額が安くなる話ではありません。月額は払い続けたうえで、自動実行の分が別払いになります。自動化を運用してきた現場にとっての実質は、この二重払いです。

経緯は要点だけ押さえれば足ります。2026年4月、GitHubがCopilot個人向け有償プランの新規販売を停止しました。定額使い放題の前提が先に行き詰まり、5月中旬から6月にかけてGitHub・Anthropic・Googleが約1か月のうちに従量制・クレジット制への移行を打ち出した、という順序です。3陣営がほぼ同時期に同じ方向へ動いた以上、個社の値上げではなく課金構造の転換と見るのが妥当でしょう。経緯の詳細年表と各社の狙いは別記事で解説しています。

影響が出る個人プラン、維持される法人契約

「うちはBusinessやEnterprise契約だから関係ないのでは」。自動化コストの見直しを社内で切り出すと、まず返ってくる質問です。実際、影響の範囲は契約形態でかなり変わります。サービス別に整理します。

GitHub Copilot

新規販売停止（4月20日）の対象は、個人向けプラン（Pro/Pro+/Student。公式FAQではMaxも対象と案内）です。6月1日のAI Credits（従量制）移行についても、公表されているのは公式ブログとFAQの範囲にとどまります。法人契約（Business/Enterprise）への適用条件は契約ごとに異なるため、確認先は自社のCopilot管理者です。管理画面の課金設定と契約条件をあわせて見れば、自社への適用範囲は短時間で特定できます。

Anthropic Claude

クレジット分離の対象は、Pro/Maxという個人向けサブスクリプションの枠内で自動実行系を使っていたケースです。API直接契約（法人利用を含む）はもともと従量課金で、今回変わったわけではありません。つまり「定額のつもりだったものが従量になる」のは、個人サブスクの枠で自動化を回していた場合に絞られます。

Google Gemini

無料枠の縮小は、個人・無償利用側の話です。企業向けライセンス（Gemini Code Assist Standard/Enterprise）の契約者は、従来どおりのアクセスが維持されると公式に告知されています。

まとめると、影響の有無は「どのサービスか」より「どの契約形態か」で決まります。自社の自動化が誰の・どの契約の認証で動いているか。この確認が、後述する棚卸しの最初の項目です。確認先は情報システム部門と各サービスの契約管理者になります。

自社の影響額を見積もる式と考え方

「うちの使用量なら関係ない」という感覚は、この領域では当てになりません。実額を断定する代わりに、試算の考え方を整理します。

式の中で効くのは呼び出し回数

月間コストは、おおよそ次の掛け算で決まります。

月間コスト ≒ 自動実行ジョブ数 × 1ジョブあたりの呼び出し回数 × 1回あたりのトークン量 × モデル単価

このうち最も効くのは「呼び出し回数」の項です。AIエージェント型の自動化は1タスクで数百〜数千回AIを呼び出すことがあります。「ジョブは数本しかないから大したことはない」という人の感覚で見積もると、桁を外しやすい構造です。

提供元自身が認めた想定超え

定額の枠を超える消費は、どの程度実在したのか。具体的な金額の公的な統計はありませんが、GitHubは4月20日の新規契約停止の際、公式ブログで「長時間・並列のエージェントセッションが、当初のプラン設計が想定した計算資源を恒常的に大きく超えるようになった」と説明しています。定額の前提を超える消費が実在したことを、提供元自身が公式に認めた形になります。先ほどの式でいえば、「呼び出し回数」と「トークン量」の項が、プラン設計時の想定の桁を超えたということです。

様子見と両立する棚卸し

「どうせまた変わる。様子見でいい」という判断には一理あります。価格も仕様も、今後また動く可能性が高い領域です。ただし、どう変わっても無駄にならない作業が一つあります。自社の自動実行ジョブの棚卸しと、使用量の把握です。課金方式がどう変わろうと、どのジョブがどれだけAIを呼んでいるかさえ分かっていれば、対応はその都度設計できます。棚卸しは様子見と両立できる、どう転んでも無駄にならない下準備です。次章で手順に落とします。

月曜から始めるコスト管理3ステップ

どのステップも、大がかりな体制づくりは要りません。今日から動ける小さな作業から始められます。

Step1 使用量のモニタリング

最初の仕事は、どのジョブが・どのモデルを・どれくらい呼んでいるかを見える状態にすることです。あわせて、前章で整理した契約形態の確認、つまり各ジョブが誰の・どの契約の認証で動いているかの特定もこの段階で済ませます。個人が自分のサブスク認証で組んだ自動化ほど把握から漏れやすく、かつ今回の変更の直撃を受けやすいためです。

まず、自動実行ジョブの一覧表を1枚作ってください。列は「ジョブ名・実行頻度・使用モデル・担当者」の4列で足ります。「日次売上レポート生成、毎朝7時、最上位モデル、営業企画A」のような1行から始めれば十分で、精緻な計測ツールの導入は後で構いません。

Step2 処理の重さに応じたモデル使い分け

すべてのジョブを最上位モデルで動かすのは、ほとんどの場合過剰です。フォーマット変換・仕分け・定型文生成のような定型処理は軽量モデルで足りることが多く、判断や推論を伴う処理だけを上位モデルに回す。この使い分けがコストの主要な調整弁になります。モデルのグレードによって単価は数倍変わります。

試すなら、Step1の一覧の中で最も実行頻度が高いジョブを1本選び、軽量モデルに切り替えて品質差を見るのが早道です。日次の集計レポート生成を軽量モデルに替え、1週間分の出力を担当者が見比べる、という程度の検証で判断できます。品質が許容範囲なら、最頻ジョブの切り替えだけで全体コストは目に見えて変わります。

Step3 ROI管理

従量課金には、不安な面だけでなく「コストが数字で見えるようになる」という面があります。これを逆手に取り、「この自動化は人件費何時間分に相当するか」をジョブ単位で記録します。削減時間・処理件数・かかったコストの3点が揃えば、続ける自動化・止める自動化・モデルを落とす自動化の判断が、感覚論ではなく数字でできるようになります。コスト管理は削るだけの活動ではなく、効いている自動化に堂々と予算を付けるための根拠づくりでもあります。

記録の始め方は単純で、Step1の一覧に「人件費換算で月何時間分か」の列を1列足して埋めるだけです。「朝バッチのレポート生成＝手作業なら月10時間」程度の粗さで構いません。時間単価も、社内の正式な換算ルールを待たず「月給÷月の稼働時間」の代理数字を仮置きすれば、この段階では十分です。

なお、ROI（投資対効果）の目安はゼロから考えるより、他社がどの業務でAIを使い何を得ているかから逆引きするのが早道です。営業・マーケから製造・バックオフィスまで11カテゴリ・50事例を、効果の概数レンジと実装難易度つきでまとめた資料があります。営業の資料作成・更新で工数50〜70%減、バックオフィスの事務工数で40〜60%減といった概数（同資料内の自社分析に基づく）は、一覧の「人件費換算」列を埋めるときの相場観としてお使いいただけます。

無料DL: AI導入50事例からみる業務部門のAI活用ガイド

棚卸しチェックリストと、属人化という次の壁

ここまでの内容は、一つの線引きに集約されます。人が対話で使う分は定額のまま、機械が自動実行する分だけが従量へ移る。直撃するのは定額サブスクの枠内で回してきた業務自動化であり、チャット中心の利用はほぼ無風です。対応の出発点は自社の使用量を知ることで、月曜の棚卸しから始められます。

社内で確認を進める際は、次の5点を順に当たってください。そのまま会議資料や情報システム部門への共有にも使えます。

自社の契約形態を確認する（個人サブスク・法人契約・API直接契約のどれか。確認先は情報システム部門か契約管理者）
自動実行ジョブの一覧を作る（ジョブ名・実行頻度・使用モデル・担当者の4列）
ジョブごとの使用モデルを把握する
最も頻度の高いジョブ1本で、軽量モデルへの置き換えを試す
一覧に「人件費換算で月何時間分か」の列を足して埋める

個人の工夫を業務プロセスへ

棚卸しを進めると、多くの現場でもう一つの壁が見えてきます。効いている自動化ほど、組んだ個人の工夫と、その個人のクレジット枠の上に乗っているという事実です。担当者が異動すれば止まり、枠を超えれば止まる。従量課金への移行は、この属人と上限の壁を数字の形で顕在化させました。だからこそ、個人の工夫を業務プロセス側に組み込み直し、誰が運用しても回る形にする道が、棚卸しの先の半歩になります。

切り分けの理解から棚卸し、モデル使い分け、ROI管理まで、ここまでの手順は社内だけでも始められます。一方で、「どの業務に・どのグレードのモデルを・いくらで使うか」というコスト可視化とROI管理の設計を業務プロセスに組み込むには、相応の知見と経験が要るのも事実です。バルテス・イノベーションズは、累計400件以上のAI開発実績をもとに、生成AI活用・AX推進の設計から運用定着までを支援しています。

棚卸しの次は、どの業務にAIが効くかの当たり付けです。部門別の事例集をあわせてご活用ください。

無料DL: AI導入50事例からみる業務部門のAI活用ガイド

自社の整理から始めたい場合は、初期診断（業務棚卸し・KPI定義）からの無料相談をご利用いただけます。

The post Claudeの従量課金移行で生成AIの料金はどう変わるか——「直撃する自動化」の切り分けとコスト管理3ステップ【2026年6月時点】 first appeared on Valtes Innovations.

なぜあなたの会社のDXは進まないのか｜72社の現場実態調査レポート

細野淳一 — Mon, 30 Mar 2026 12:09:24 +0000

このレポートが刺さる方

経営層からDX推進を任されたが、何から始めるかが決まらない
既存システムのブラックボックス化が進み、移行・改善に着手できない
DXツールを導入したのに現場に定着しない、成果が出ない

上記に一つでも当てはまる方へ。このレポートは72社の現場実態から、その原因と出口を示します。

1. 調査概要

2025年は、経済産業省が2018年に発行した「DXレポート（2025年の崖）」が指摘した”約束の年”です。あれから7年、日本企業のDXは本当に変革を遂げたでしょうか。

バルテス・イノベーションズでは現場の声を直接収集し実態を可視化するため、DX推進ウェビナーを開催しました。本レポートはその参加企業のアンケート結果をもとに作成した実態調査です。

調査期間	2025年8月22日〜9月16日
有効回答数	72件
対象	DX推進ウェビナー申込・参加者
調査方法	Webアンケート（申込時・当日）

参加者プロフィール

89%

従業員100名以上の
中堅〜大企業

44%

製造業
（最多業種）

75%

一般〜課長クラス
現場DX担当者層

本調査は「現場を理解しつつ、DX推進の責任も担うミドル層」を中心とした実態調査です。業種は製造業が最多（44%）ですが、IT・コンサル、商社、教育、医療、運輸と多様な業種が参加しており、DXへの課題意識が業種横断で広がっていることを示しています。

2. データが示す実態 ─ 72社の現場で何が起きているのか

発見① 「何から始めるか」で止まっている企業が大多数

製品・サービスの導入検討状況を聞いたところ、次の結果になりました。積極的に選定を進めている企業はわずか13%にすぎません。

社内で検討中（課題確認・情報収集）

44%

様子見・情報収集

38%

候補製品を探している

11%

既に候補を絞り評価中

導入済み

発見② DXが「これから／結果がまだ出ていない」企業が58%

DXの取り組み状況は「これから／結果がまだ出ていない」が58%と過半数。「Go/Noの判断ができない」「上申できる状態になっていない」という声と一致します。

発見③ 「電子化＝DX」という誤解が根強い

自由記述から最も多く見られたのは次の2テーマです。DX推進担当としては単なるデジタライゼーションの先を考えていても、会社の巻き込み・推進には課題を感じているようです。

「電子化・デジタル化をDXと同一視している社内をどう是正するか」
「ツール導入が目的化し、現場が使いこなせていない」

参加者の声（自由記述より）

「『電子化』＝『DX』の認識が社内で強いので、改めて社内に説明するための情報収集に来た」

参加者の声（自由記述より）

「ツール導入が先行している。単なる自動化をDXと勘違いしている。まあ何もしないよりはましな状態」

これは特定の企業だけの課題ではありません。三菱総合研究所が1,000社を対象に実施した調査でも、同じ構図が見えています。

「想定通りの成果が出ている」割合は、ビジネス変革段階の企業では 44.5%。一方、デジタライゼーション段階の企業では 14.6%にすぎない。DXは「変革を実現する企業」と「電子化で終わる企業」に二極化しつつある。

─ 三菱総合研究所「DX推進状況調査結果【2025年度速報版】」（n=1,000、2025年1月）

3. なぜDXは「電子化」で終わるのか

「よくあるストーリー」

多くの企業でこのシナリオが繰り返されています。

経営層から「うちもDXを進めろ」と号令が下りる
IT部門がコストダウンやシステム更改に着手する
PoC後にシステムを本格導入するが、現場の利用は限定的
追加開発が続き、当初想定外のコストが発生する
経営層は「DXが成功した」と満足し、HPでも宣伝される

「社長、それDXじゃないです。」

DXの定義に立ち返る

DXを提唱したエリック・ストルターマン教授の定義はシンプルです。

“The changes that digital technology caused or influences in all aspects of human life”
「デジタル技術が人間の生活のあらゆる面にもたらす変化」

どの定義にも共通するのは、「変革（Transformation）が目的であり、デジタルは手段」であること。「FAXをPDFにした」「ハンコをなくした」はデジタイゼーションであり、DXではありません。

3段階のフレームワークで自社位置を確認する

情報処理推進機構（IPA）の「DX実践手引書」は、DXを3段階で整理しています。

段階	概念	典型例
①	デジタイゼーション	帳票の電子保存、FAXのメール化
②	デジタライゼーション	勤怠管理クラウド化、在庫リアルタイム管理
③	デジタルトランスフォーメーション	文化・風土の改革、新規事業創出

IPA「DX動向2025」は「DXの目的はコスト削減・業務効率化に偏重しており、新規ビジネス創出を実現する企業は少ない」と指摘しています。③を目指すために必要なのは、「目的から逆算すること」と「現状を正確に把握すること」の2点です。

4. DXの最初の壁 ─ 現状が見えないから動けない

アンケートデータとバルテス・イノベーションズへの日々のご相談を照らし合わせると、同じ構図が浮かび上がります。

「ありたい未来・あるべき姿」が経営層の頭の中にしかない

↓

既存の業務フローもシステムも、全体像が誰にも見えていない

↓

判断材料がないまま、ツール提案が先行する

↓

現場と経営層の認識がずれ、投資判断が止まる

↓

「何をもって成功とするかわからない」状態に陥る

DXの最初の壁は、技術でも予算でもなく
「現状が見えていないこと」です。

立場別に見える「リアルなペイン」

アンケートへの声と日々のご相談を照らし合わせると、3つの立場で共通のパターンが浮かび上がります。

こんな方 ── 経営層からDX推進を任されたミドル〜マネージャー層

「成果を出せと言われているが、何から始めるか不明確。コンサルに頼んだらツール提案しか来なかった。経営層に説明できる絵が描けない」

なぜ起きるか：「ありたい未来」と「現状のギャップ」が見えていないため、施策を優先順位付けできない。ベンダーは製品ありきで提案するため、現状整理を手伝ってくれない。

こんな方 ── 既存システムの維持・移行を担う情報システム部門

「既存システムの設計書がない。誰もブラックボックスを理解していない。このまま新システムに移れる気がしない」

なぜ起きるか：長年の改修でドキュメントが追いつかず、仕様が属人化。担当者の異動・退職とともに知識が失われ、「触ると壊れる」状態が放置されている。

こんな方 ── DXの名のもとにシステム導入を押しつけられた現場担当者

「現場にシステムを入れても誰も使ってくれない。かえって業務が増えた。『DX推進』という名目で余計な仕事が降ってくる」

なぜ起きるか：現場の業務フローを整理しないまま、ツールが先行導入される。「入れたら使われる」は幻想で、定着には現状把握と合意形成が必要。

これらのペインは、すべて「現状が可視化されていない」という同じ根に起因しています。

5. なぜ「現状の可視化」は行われないのか

現状可視化の重要性は多くの資料で指摘されています。それでも実行されない理由が、現場には5つあります。

① レガシーシステムのブラックボックス化

設計書が残っておらず、担当者も異動・退職済み。「触ると壊れる」「誰も全体を知らない」という状態が放置されています。

② 業務プロセスの属人化

標準フローが存在せず、個人の頭の中にしかない。「Aさんがいないと回らない」業務が各部門に複数あります。

③ IT部門だけでは業務実態を把握しきれない

技術はわかるが業務詳細は現場しか知らない。現場を巻き込む余裕も方法もわからない。

④ ベンダー提案が「ツール前提」になっている

現状整理に時間を割かず、製品ありきで提案が来る。「要件がわからない状態でRFPを書く」という悪循環。

⑤ 可視化のスコープが絞れない

「どこから手をつけるか」が決まらず、全体を可視化しようとして頓挫します。

「現状が見えないままDXプロジェクトが走り出す」。これが失敗確率を最も高める要因です。

6. 現状可視化からDX、そしてAXへ ─ 3つのステップ

今回のアンケート参加者の多くは「ステップ1と2の間」で悩んでいました。裏返せば、この間を支援できるパートナーの価値が最も高いことを意味します。

As-Is（現状）の可視化

業務プロセスの棚卸し・標準フロー整理
既存システムの機能構造・連携関係の把握
属人化ポイント・ボトルネックの洗い出し
レガシーシステムのリバースエンジニアリング

ゴール：「誰が何をどのフローで行っているか」が1枚の絵で見える状態

To-Be（あるべき姿）の合意形成

経営・現場・IT部門の三者で「目指す姿」を言語化する
「何をDXと呼ぶか」「どの指標で成功とみなすか」を明確化する
「目の前のTo-Be」と「その次のTo-Be」のフェーズ設計

DXはトップダウンが原則ですが、現場の納得なしには定着しません。三者が腹落ちする合意形成こそ、この段階の核心です。

ゴール：全員が同じ言葉で話せる状態。経営層への稟議が通る根拠が揃う

AI業務革新（AX）への展開

Step 1〜2が揃うと、初めて明確に見えてくるものがあります。「この業務は、AIで置き換えられる」という判断軸です。

業務の特性	AXでの対応
繰り返し発生する定型作業	AI自動化による工数削減
外注・BPOに出している業務	監査証跡を保ちながらAI内製化
紙・手作業・属人化した判断業務	AIによる標準化・スケール化

「外注・BPOで回している業務を、監査対応を崩さずにAIで置き換える。AIが実行し、人が承認する。責任分界まで設計して本番運用へ。」

44.5%

ビジネス変革段階
「想定通りの成果」

14.6%

デジタライゼーション
止まりの企業

─ 三菱総合研究所「DX推進状況調査結果【2025年度速報版】」（n=1,000、2025年4月）

現状可視化→To-Be合意→AXという順接が、この成果の二極化を分けるカギです。三菱総研の調査によれば、生成AIの業務利用率は2023年の25.5%から2025年には45.7%へ急増。AX活用は「先進的な取り組み」ではなく、経営課題への現実解になりつつあります。

7. バルテス・イノベーションズが提供できること

DX支援を行う会社は多数存在します。しかしバルテス・イノベーションズが持つ組み合わせは他にありません。

強み	内容
DXの一気通貫	コンサルから開発・運用・テストまでワンストップ。「コンサルだけ・開発だけ」にならない
品質保証DNA	バルテスグループの品質・テスト知見をDX・AI設計に適用
AXまでの順接支援	DXコンサルの延長としてAIを武器化。PoC→本番移行まで伴走
既存資産を活かす	リバースエンジニアリングで既存システムを可視化。「捨てるか使うか」から支援

支援実績

大手製造業｜基幹業務DX化プロジェクト

課題

受発注・請求・購買管理が属人化。データが散在し経営指標をリアルタイムに確認できない。

支援

業務プロセスの可視化（As-Is）→ To-Be策定 → 各部門への説明 → 要件定義〜開発まで一貫支援。

成果

業務生産性が飛躍的に改善。BIツールによるリアルタイム経営指標の確認を実現。

研究機関｜実験資材管理業務DX化

課題

Excel・独自ツールの長年運用により、新担当者がデータを正しく扱えずミスが多発。業務負荷が慢性的に高い。

支援

業務フロー調査解析 → 業務フロー見直し → 要件定義（プロトタイプで現認）→ API連携による自動化。

業務工数 60%削減業務プロセス・工数削減実績

まとめ

DXの定義が共有されていない。ツール導入や電子化を「DX完了」と捉えてしまい、変革に至っていない企業が多数です。まず「何のためのDXか」を三者で合意することが先決です。

現状が見えていないまま前に進んでいる。業務プロセスの属人化とレガシーシステムのブラックボックス化が最大の障壁です。判断材料を揃えるためにも、現状可視化が最初のアクションです。

DXの先にAXがある。現状が見えて、To-Beが合意できると、初めて「どこをAIに置き換えるか」が決められます。DX→AXは無理に接続するものではなく、正しく進めれば自然に辿り着く道筋です。

「ありたい未来から逆算し、現状を正確に把握する。そこから始める。」
DX推進を任された方も、現場でシステムに悩む方も、出発点は同じです。

DXの現状整理、まずご相談ください

バルテス・イノベーションズでは、DX推進の現状整理・To-Be策定について初回無料相談を受け付けています。

DX全体

現状整理・To-Be策定の無料相談

AI活用・AX

業務棚卸し・置換可能性診断（2週間）→ 概算ROI提出

レガシー課題

AIリバースエンジニアリングPoC→ 既存システム可視化

まずは無料相談する資料ダウンロード

本レポートについて

監修：仁加保徹（ITストラテジスト / バルテス・イノベーションズデジタルソリューション部）

資格：情報処理技術者試験 ITストラテジスト / 一般社団法人日本ITストラテジスト協会正会員

引用：三菱総合研究所「DX推進状況調査結果【2025年度速報版】」（2025年4月）/ IPA「DX動向2025」（2025年6月）

The post なぜあなたの会社のDXは進まないのか｜72社の現場実態調査レポート first appeared on Valtes Innovations.

レガシーシステムとは？脱却が進まない要因と3つの脱却方法を解説【チェックリスト付き】

細野淳一 — Fri, 31 Oct 2025 10:33:33 +0000

「自社のシステムが古くなってきているのは感じるものの、どこから手をつけてよいのか分からない」「運用コストばかりかかって新しい施策に投資できない」と悩む企業担当者は少なくありません。

しかし、レガシーシステムは、刷新が必要だと分かっていても、コストの高さやIT人材不足、経営層の危機感の欠如など複数の課題が絡み合い、思うように脱却が進まないのが現実です。

そこで本記事では、レガシーシステムの定義を技術面と経営面から整理し、チェックリストで現状を確認できるようにしたうえで、脱却が進まない背景と3つの解決アプローチを分かりやすく解説していきます。

レガシーシステムの定義

レガシーシステムとは、古いからではなく「変更しにくく、維持にお金と手間がかかり、事業の足かせになっている既存システム」のことを指します。まずはレガシーシステムとは何を指すのか？について以下2つの視点から解説します。

①技術的観点からの定義

技術的観点でのレガシーシステムとは、老朽化した技術基盤や複雑化した構造が原因で、保守・改修・拡張が困難になっている既存システムを指します。

サポートが終了した古いOSやプラットフォームが使われており、最新バージョンへのアップグレードが難しいケースが多いです。

また、長年の改修で設計が肥大化・複雑化して全体像を把握しづらくなり、さらに設計書やソースコードが十分に残されていないため「ブラックボックス化」するリスクもあります。

例えば、当初の開発者が退職し、内部構造を理解できる人が不在となることで、機能追加や不具合対応に大きな障害が生じるケースが典型です。逆に、継続的に保守・改修され、利用可能な状態であれば必ずしもレガシーとはみなされません。

② 経営的観点からの定義

経営的観点でのレガシーシステムとは、IT投資不足や旧態依然とした業務慣行の維持によって、企業の成長や競争力強化を阻害しているシステムを指します。

経営層がIT投資を「コスト」と捉えて予算を割かず、既存の制度やプロセスに固執する場合、システムの刷新が遅れ、老朽化を招きやすくなります。また、経営層自身がデジタル化の必要性を理解しておらず「現状で動いているから問題ない」と考える危機意識の欠如も深刻な要因です。

こうした状況では、現場からの技術的な警告が経営判断に反映されず、結果として刷新のタイミングを逃し、企業全体のDX推進を阻害する要因となります。

レガシーシステムを放置する危険性

レガシーシステムは放置されがちなのが実情です。しかし、レガシーシステムをそのまま使い続けると、以下のようなリスクが生じます。

バージョンアップできない
セキュリティパッチが当てられない
保守できる技術者がいない

これらの問題が重なると、組織全体の生産性が低下し、最悪の場合、事業継続に重大な支障をきたします。

経済産業省も「2025年の崖」と呼ぶ警鐘を鳴らし、レガシーシステムを放置したままでは高額な経済損失が生じると指摘しています。

レガシーシステムかどうかのチェックリスト

レガシーシステムは、実際にそうでないケースや逆にレガシーシステムだったという場合もあります。自社のシステムがレガシーに該当するか判断するため、以下の項目に当てはまるか確認してみましょう。

チェック項目	チェック
保守/運用費がIT予算の70％超
小改修でもリードタイムが数週間
主要ソフト/ハードがEOL/EOS
属人化で担当不在時に止まる
システムの仕様・設計がドキュメント化されておらずブラックボックス化している

これらに当てはまる項目が多いほど、システムは実質的にレガシー化している可能性が高いといえます。その場合、単に「古いから置き換える」のではなく、ビジネスに与える影響度やリスクを定量的に評価することが重要です。

レガシーシステムの脱却が進まない要因・問題点

レガシーシステムの脱却が進まない要因・問題点は主に以下の4つです。

要因①IT人材の不足

国内のIT人材不足は年々深刻さを増しており、経済産業省は2030年には約79万人もの人材が足りなくなると予測しています。

出典：経済産業省｜IT人材育成の状況等について

特に、既存システムの維持や運用を担える経験豊富な技術者が減少しており、ブラックボックス化したレガシーシステムに対応できる人材は限られています。

結果として、企業は「古いシステムを維持するにも人手が足りない」「刷新を進めたくても設計を理解できる人がいない」という二重の課題を抱えることになります。

IT人材の不足は単なる採用難にとどまらず、システムの安定稼働そのものに影響を及ぼす大きなリスクとなっているのです。

要因②移行コストの高さ

システムを刷新するには、開発費・導入費・テスト費用・教育コストなど大規模な投資が必要です。その上、既存ベンダーに依存している場合には、高額な保守料やライセンス費用を払い続けざるを得ず、コスト構造が硬直化してしまいます。

このような状況では、費用対効果の悪化が表面化する一方で、「現状維持のほうが短期的には安全」という判断が優先されがちです。

また、移行プロジェクト中にシステム停止が発生するリスクや、業務フローが一時的に混乱する懸念も、投資判断を鈍らせる要因になっています。

要因③経営層のデジタルリテラシー・危機感不足

レガシーシステムが脱却できないのは、経営層がITやデジタル戦略を「事業成長の武器」ではなく「コスト要因」と見てしまうケースからもあります。

その結果、必要な予算が確保されず、刷新計画が先延ばしにされることになります。さらに、「現状のシステムで業務が回っているから問題ない」という判断から、危機感が薄れ、競争力の低下に気づくのが遅れる場合もあるのです。

本来であれば経営層が率先してデジタル化を推進すべきですが、意思決定層が必要性を理解しない限り、現場からの改善提案も経営判断に反映されにくくなり、組織全体の変革スピードが停滞してしまうのです。

要因④機能の要不要が不明・ドキュメント不在

長期にわたって使われてきたシステムでは、当初の開発者がすでに退職していたり、設計書や仕様書が失われていることが珍しくありません。

そのため、「どの機能が現在も利用されているのか」「不要な機能はどれか」といった判断ができず、移行計画を立てる段階で行き詰まるケースが多く脱却ができないのです。

このような状況では、リバースエンジニアリングなどの手法で既存資産を解析し、利用状況を可視化する取り組みが必須になります。しかし、分析には高度なスキルと工数が必要であり、結果として停滞することも少なくありません。

レガシーシステムを脱却する3つの方法

では、上記の脱却できない要因を踏まえてどのように脱却するべきなのか、3つの方法を解説します。

方法①モダナイゼーション

モダナイゼーションは、既存の資産を活かしつつシステム全体を最新技術に近代化する手法です。情報資産やノウハウは残したまま、システムのアーキテクチャやコードを刷新していきます。取り組みは、主に以下の3つがあります。

システム全体を新規構築する「リプレイス」
基盤やOSごと移し替える「リホスト」
プログラム言語を変えて書き直す「リライト」など

モダナイゼーションは、業務要件に合わせて古い部分と新しい部分を分割しながら改善できるため、途中で業務停止を避けつつ安全に進められるメリットがあります。一方、既存部分を残しての修正となり、プロジェクトの費用や規模は大きくなる傾向があります。

実際に製造業では、老朽化した生産管理システムを最新アーキテクチャに刷新することで、停止リスクを最小化した成功事例も。また、サービス業においては、既存の顧客データベースを段階的にリライトしながら、利用継続と機能改善を両立したケースもあります。

方法②マイグレーション

マイグレーションは、既存のシステムやデータを新しい環境・プラットフォームへ移行する手法です。データや機能を基本的に維持しつつ、システム基盤のみをクラウドや新サーバーに置き換えます。

オンプレミスからクラウドへの移行や、新旧両環境を併用するハイブリッド構成への切り替えなどが該当します。マイグレーションのメリットは、業務を止めずに段階的に移行できる点です。

要件や機能を変えずに移せるため、リスクやリソースを抑えながら実行できます。ただし、環境が変わることで業務フローに調整が必要になるケースもあるため、事前準備やテストは慎重に行う必要があります。

金融業では、高額なオンプレ環境の維持費を削減するため、段階的にクラウド基盤へ移行した事例があります。バルテス・イノベーションズでは移行計画をリスク診断とセットで行うため、システム停止やセキュリティ面の不安を事前に回避できます。

方法③クラウド移行

クラウド移行は、オンプレミスのサーバーやストレージを廃止し、システムやデータをクラウドサービス上に移す手法です。クラウド環境に移行することで、必要に応じた柔軟なリソース拡張が可能になります。

また、運用保守に関わる負担を軽減でき、コスト削減や障害対応の効率化につながるメリットがあります。移行にあたっては、現状のシステム資産をどこまでクラウド化するかを事前に分析し、移行計画を策定することが重要です。

段階的なマイグレーションやハイブリッド戦略を組み合わせるなど、自社に最適な戦略で進めましょう。

クラウド移行は単なるインフラ移動ではなく、業務継続性や拡張性を高める重要な戦略です。VINでは、リバースエンジニアリング → 移行リスク診断 → クラウド移行という流れを組み込み、現場の負担を抑えながら安全に移行を進めます。

さらに大きな課題は、「現状システムを正しく把握できないこと」にあります。設計書が残されていなかったり、どの機能が使われているか不明なケースも多く、移行判断そのものが困難になります。

バルテス・イノベーションズでは、リバースエンジニアリングによって既存システムを解析し、利用状況を可視化したうえで移行リスクを診断します。その結果に基づき、段階的にモダナイズやクラウド移行を進められるため、手戻りや失敗のリスクを大幅に減らせます。

レガシーシステムからの脱却はバルテス・イノベーションズまでご相談ください

本記事では、レガシーシステムの概要から脱却の方法まで詳しく解説しました。レガシーシステムからの脱却には、技術・コスト・組織といった調整が求められ、専門的な知識や経験が必要です。しかし、ノウハウがなければすぐに改善するのは難しいでしょう。

バルテス・イノベーションズでは、システムモダナイゼーションやマイグレーション、クラウド移行など各種ソリューションの提供実績があります。自社の状況に合わせた最適なモダナイズ戦略の立案・実行支援が可能ですので、レガシーシステムの課題でお悩みの際はぜひ当社までご相談ください。

The post レガシーシステムとは？脱却が進まない要因と3つの脱却方法を解説【チェックリスト付き】 first appeared on Valtes Innovations.

要件定義とは？発注時に押さえておくべき3つのポイント

細野淳一 — Fri, 05 Dec 2025 09:33:42 +0000

システム開発を検討している企業や担当者の中には、「発注先に要件を伝えたつもりなのに成果物が思い通りにならない」といった悩みを抱える方が少なくありません。

こうした問題の多くは、プロジェクトの土台となるシステム要件定義が不十分であることが原因です。システム要件定義とは、開発対象の目的や機能、性能、運用環境などを整理し、発注側と開発側が共通認識を持つための工程です。

この段階で内容を明確にすることで、開発後の手戻りを防ぎ、納期やコストの増加を抑えられます。本記事では「システム要件定義とは？」を解説し、発注時に押さえるべき3つの重要ポイントを紹介します。

⇨バルテスイノベーションズの詳細はこちら

システム要件定義とは？

システム要件定義とは、これから開発するシステムが「何を実現するべきか」「どのように利用されるのか」といった目的や機能、性能、利用環境などを具体的に整理し、発注者と開発者の間で共通の理解を持つためにまとめる工程のことです。

明確にすることで、開発中の認識のズレや後からの仕様変更による手戻りを防ぎ、納期やコストを無駄にしないスムーズなプロジェクト進行が可能になります。

要件定義と要求定義の違い

システム要件定義と要求定義は混同されがちですが「工程」に違いがあります。以下の表でまずは違いを理解しておきましょう。

項目	要件定義	要求定義
目的	要求をシステムでどう実現するかを仕様化する	利用者やビジネス側が実現したいことを明確化する
視点	開発者目線・技術目線	ユーザー目線・ビジネス目線
内容	機能要件、非機能要件、利用環境、連携方法などを具体化	業務上の課題、欲しい機能、理想像などを整理
成果物	システム要件定義書、機能仕様書のベース	要求一覧、課題リスト、ビジネスゴール
例	「スマホからアクセス可能なWebアプリを開発する」	「外出先から顧客情報を見たい」

要求定義は「何をしたいのか」という利用者のニーズやビジネス上の目標を洗い出す工程であり、システム開発の出発点です。その後に行うシステム要件定義では、要求定義で明らかになったニーズをシステムとしてどう実現するかを具体的な仕様に落とし込みます。

システム要件定義書を依頼する際に押さえておくべきポイント

まずはシステム要件定義書を依頼する際に押さえておくべきポイントを3つ紹介します。

ポイント①どこまでベンダーに任せるのか明確にする

システム要件定義書を作成する際に大切なのは、ベンダーにどこまで任せるのかを最初に明確にしておくことです。

なぜなら、発注者とベンダーの役割があいまいなまま進めてしまうと、後から「ここは誰が決めるのか」「どこまで対応してくれるのか」といった認識のズレが生じ、トラブルや追加費用につながる可能性が高いからです。

基本的にシステム開発は、発注者が主体的に「どんなシステムを作りたいのか」を決め、その実現方法や技術的な部分をベンダーが支援するという形で進みます。つまり、要件定義はあくまで自社が責任を持って意思決定するものであり、ベンダーに丸投げしてはいけません。

ポイント②要件の優先順位を伝える

システム要件定義書を依頼するときは、要件に優先順位をつけてベンダーに伝えましょう。なぜなら、すべての機能を一度に盛り込もうとすると、費用も期間も膨れ上がり、プロジェクト全体が破綻するリスクがあるからです。

そこで、必ず必要な「必須機能」と、あれば便利な「追加機能」を分けて提示することで、ベンダー側も費用や工数の見積もりを行いやすくなります。

また、優先順位を設定することで、万が一スケジュールや予算が厳しくなった場合でも、削るべき機能や後回しにできる部分を判断しやすくなります。結果として、要件定義の段階からコストやリスクを現実的に評価でき、よりスムーズな調整が可能になるのです。

ポイント③現場社員抜きでベンダーとやり取りしない

システム要件定義を進める際にやってはいけないのが、現場の社員を巻き込まずにベンダーと発注担当者だけでやり取りしてしまうことです。

実際にシステムを使うのは現場社員であり、日々の業務の流れや困っている課題を一番よく知っているのも現場の人たちです。その声を反映しないままベンダーに依頼を進めてしまうと、完成したシステムが「使いにくい」「実務に合っていない」という問題が発生し、投資が無駄になってしまうリスクがあります。

現場社員を早い段階から打ち合わせに同席させれば、要件の抜け漏れを防ぎ、より現実的で使いやすいシステム設計になるでしょう。さらに、現場の意見を反映することで導入後の利用定着率も高まり、「せっかく作ったのに誰も使わない」といった事態を防ぐ効果も期待できます。

システム要件定義の成功事例

ここではシステム要件定義の成功事例を2つの業種で紹介します。

事例①製造業

ある製造業の基幹システム刷新プロジェクトでは、初期段階で要件定義を曖昧にした結果、追加機能要望が次々に発生し、開発コストが予定の1.5倍に膨らむトラブルが起きていました。

その後、外部の専門的なサポートを受けながら以下の様に改善策を行いました。

現場ヒアリング
必須／追加機能の優先度設定
非機能要件の明文化（レスポンス速度、稼働率など）

結果、再設計した要件定義書をベースにプロジェクトをリカバリーします。結果として開発期間を3か月短縮し、運用コストも20％削減できました。

事例②サービス業

サービス業（多拠点展開企業）の予約管理システム刷新プロジェクトでは、経営企画部門と現場運用部門で必要要件が分断されており、ベンダー提案も「丸投げ」状態でした。

そこで、第三者が要件定義フェーズから加わり、現場業務フローを整理して「必須要件（基幹システムとの連携、24時間稼働）」と「拡張要件（モバイル予約、分析機能）」を分離しました。

さらに非機能要件を明文化したことで、プロジェクト開始前に見積り精度を高め、導入後のシステム稼働率を99.7％に安定化させることに成功しました。

システム要件定義書の作成で失敗しない進め方

システム要件定義書の作成は単に作成するのではなく、以下4つのステップで進めましょう。

ステップ①目的と課題を整理する

システム要件定義書を作成する前に重要なのは、いきなりベンダーに依頼するのではなく、自社の業務フローや現状の課題をしっかり洗い出しておくことです。

課題が不明確なまま依頼をしてしまうと、ベンダー側も解決すべきポイントを正しく把握できず、結果的に「使えないシステム」が出来上がってしまう危険があります。

この整理を行う際には、必ず現場の担当者にヒアリングを行い、実際の困りごとや改善したい点を生の声として集めましょう。事前準備を丁寧に行っておくことで、ベンダーに正確な情報を伝えられ、要件定義がスムーズに進む土台を作ることができます。

ステップ②理想の業務フローを描く

現状の課題を把握したら、次はシステムを導入することでどのように業務を効率化したいのか、理想の業務フローを描くことが大切です。

ただ「便利なシステムがほしい」と考えるのではなく、「なぜこれをシステム化するのか」「どの業務を自動化し、どの業務を人間が担当するのか」といった役割分担を明確にしておく必要があります。

この段階で理想像を定義しておくことで、システムが解決すべき課題と期待される成果が具体的になり、ベンダーも開発の方向性を見誤ることなく設計を進められます。漠然としたイメージではなく、紙に業務フローを図解するなど「目に見える形」にすることで、自社内での共有も容易になり、発注時の説明にも役立ちます。

ステップ③機能要件だけでなく非機能要件も明確にする

システム要件定義というと、多くの人は「どんな機能が必要か」を考えがちですが、それだけでは不十分です。以下のような非機能要件も、利用者にとっては重要なポイントになります。

システムの操作性
レスポンス速度
セキュリティや可用性

たとえば「顧客検索機能がある」だけでなく、「検索結果が2秒以内に表示されること」や「スマホからもスムーズに利用できること」といった条件を明記することで、使いやすく信頼できるシステムになるでしょう。

また、すべてを一度に要求するのではなく「必須」「あればよい」「将来的に検討」といった優先順位をつけて伝えることで、費用や期間の調整がしやすくなり、現実的な開発計画が立てられます。

ステップ④定期的にミーティングを実施する

要件定義書の作成をベンダーに依頼したら安心、という考え方は失敗の原因になりやすいです。発注して終わりではなく、定期的にベンダーと打ち合わせを行い、進捗や内容を確認し続けることが大切です。

やり取りを怠ると、出来上がった要件定義書を見たときに「想定と違う」「認識がずれていた」といった問題が発覚し、大量の修正作業が必要になってしまうためです。定期的にミーティングを設定することで、双方の認識のズレをその場で解消でき、余計な工数やコストの増加を防げます。

また、現場の意見や新たに見つかった課題を迅速に反映できるため、実際の業務に即したシステムを形にすることが可能です。

システム要件定義書の作成依頼の注意点

システム要件定義書の作成を依頼する際は、以下3つの点に留意しましょう。

注意点①自社の事業を理解していないベンダーはNG

システム要件定義を依頼する際に避けるべきなのは、自社の事業内容や業務特性を理解していないベンダーに任せてしまうことです。

たとえば物流業と医療業界ではシステムに求められる機能や法的規制、現場での使われ方が異なります。業界知識のないベンダーでは表面的な要件だけを整理してしまい、本当に現場で役立つ仕組みが作れない可能性があるのです。

そのため候補を選ぶ段階では、必ず同業界や類似業務での要件定義やシステム導入の実績があるかを確認することが大切です。仮に経験が少ない場合でも、現場担当者に丁寧なヒアリングを行い、課題を深く理解しようとする姿勢があるかをチェックすれば、依頼後のすれ違いやトラブルを減らせます。

注意点②5W1Hを意識したヒアリングをしてくれるか

ベンダーが行うヒアリングで重要なのは「誰が・何を・いつ・どこで・なぜ・どのように」という5W1Hを意識しているかどうかです。

これらの視点を持たずに質問をされると、曖昧な要件しか洗い出せず、完成したシステムが現場で使えないものになってしまう恐れがあります。

Who（誰が）	どの部署・どの担当者が利用するのか
What（何を）	どんな業務やデータを扱うのか
When（いつ）	どのタイミング・どの頻度で使うのか
Where（どこで）	オフィス・現場・外出先など利用場所
Why（なぜ）	なぜその業務をシステム化する必要があるのか
How（どのように）	具体的な利用方法や操作フロー

5W1Hを軸にしたヒアリングをしてくれるベンダーは、業務を多面的に理解し、利用者にとって本当に役立つ要件を定義できます。

注意点③スケジュール通りに実施できているか

要件定義は契約形態上「準委任契約」となることが多く、必ずしも成果物を保証するものではありません。そのため、発注者側が受け身でいると「想定より進みが遅い」「要件がまとまらない」といった遅延が発生しやすいのが現実です。

そこで大切なのは、発注者自身が積極的にスケジュール管理に関与し、要件定義フェーズだけでもマイルストーンを設定しておくことです。

例えば「2週間ごとの進捗報告」「遅延が発生した場合の原因報告と対策提示」などをルール化しておけば、不測の事態が起きても対応がスムーズになります。また、ベンダーが独自の進行管理体制を持っているかどうかも事前に確認しておきましょう。

システム要件定義はバルテス・イノベーションズまでご相談ください

システム要件定義は、開発の成否を左右する重要工程であり、ここを曖昧にしたまま進めると「完成したのに使えない」「コストや納期が膨らんだ」といった失敗につながります。

だからこそ、自社の目的や課題を整理し、理想の業務像を描いたうえで、機能と非機能を分けて定義し、ベンダーと定期的に認識を合わせることが大切です。

要件定義書を作成したものの「合っているかわからない」という方は、バルテス・イノベーションズへご相談ください。バルテス・イノベーションズでは、お客様の課題やシステム開発の要件を丁寧にヒアリングし、要件定義からシステム開発を伴走します。

バルテス・イノベーションズへのお問い合わせはこちら

The post 要件定義とは？発注時に押さえておくべき3つのポイント first appeared on Valtes Innovations.

アプリのUI/UX改善の方法を4つのステップで解説！成功するコツや事例も紹介

上西渡累 — Thu, 18 Sep 2025 08:36:39 +0000

アプリを公開しても利用率が上がらない、機能を追加しても期待ほど使われないと悩むケースは少なくありません。UI/UXの質はサービスの成果を大きく左右します。見た目を整えるだけでは不十分で、ユーザーの行動や心理を踏まえた体系的な改善が欠かせません。

本記事では、UI/UXを効果的に改善するための4つのステップを順を追って解説します。

UI/UXの改善とは？

本校で述べるUI/UXの改善とは、以下の観点でより快適で使いやすくするために見直す取り組みを指します。

UI：画面やデザインの見た目
UX：利用全体を通じた体験

機能が優れていても、操作が複雑であったりデザインが見づらかったりすれば、ユーザーは不便を感じて離れてしまいます。したがって、UI/UX改善は「顧客満足度の向上」「継続利用率の確保」「競合との差別化」という3つの点で欠かせない取り組みと言えます。

UI/UXの改善をするメリット

アプリのUI/UXを改善するメリットは、見た目だけの改善ではありません。主に以下のメリットがあります。

継続利用率が伸び、LTVが向上する
無駄機能の削減と優先度の明確化で、開発投資のROIが改善する
使いやすさが口コミ・レビューに反映され、ブランド信頼や評判が向上する

上記のようにUI/UXを体系的に磨くことは、目先の見栄えを整える作業ではなく、集客効率やコンバージョン、継続率など多面的に効く事業の基礎体力づくりです。限られたリソースでも優先度の高い改善点に集中することで短期の数値改善と中長期の競争優位を同時に実現できる点がメリットです。

UI/UXを改善する4つのステップ

UI/UXを改善する際は、やみくもに進めるのではなく以下4つのステップで進めましょう。

ステップ①ユーザビリティテストやアンケートを実施

UI/UX改善の最初のステップは、現状の課題やユーザーの本当のニーズを知るために「データ分析」と「ユーザー調査」を行うことです。具体的には、ユーザビリティテストやアンケートを通じて、以下の様な顕在的ニーズを把握します。

今まさに不便だと感じていること
改善してほしい要望

ユーザーインタビューや行動観察などを行うことで、ユーザー自身が気づいていない潜在的なニーズも掘り起こせます。この調査によって、なぜ離脱が起きているのか、どこにストレスを感じているのかといったUXの根本課題が浮き彫りになるため、改善の土台として最も重要なプロセスといえます。

ステップ②ユーザーの要求を整理する

調査で得られた情報は、そのままでは活かしづらいため、整理と構造化が必要です。例えば「上位下位関係分析法」を用いてニーズを階層化すると、「なぜその要望があるのか」「その背景にある根本課題は何か」が明確になります。
また、ペルソナを設定して代表的なユーザー像を描くことで、誰に向けた改善なのかを具体化できます。そしてカスタマージャーニーマップを作成し、ユーザーがサービスを利用する流れの中で「どこで迷うか」「どんな感情になるか」を時系列で整理しましょう。UX上の摩擦点やつまずきやすいポイントが浮き彫りになります。
この工程により、改善の優先度が高いポイントを的確に特定できます。

ステップ③課題に対するプロトタイプを作成

整理されたユーザー要求をもとに、実際に解決策を形にしていきます。この段階で大切なのは、完璧なデザインを目指すことではなく「素早く検証できる仮のUI」を作ることです。ワイヤーフレームやFigmaなどのツールを使ってプロトタイプを作成し、ボタンの配置、導線、文言、色合いなどを試しながら仮のUIを作ります。

この過程は、机上のアイデアを具体的な形にし、実際の利用イメージを確認できるため、後続の評価プロセスで実用的なフィードバックを得やすくなります。スピード重視で小さく試し、早めに修正できる状態にするのが成功のコツです。

ステップ④UX評価とユーザビリティ評価を実施

最後のステップは、作成したプロトタイプを実際のユーザーに使ってもらい、その体験を評価する工程です。評価は大きく2つに分けられます。

評価の種類	評価の内容	具体的な観点
①UX評価	利用中の感情や全体的な満足度を測る	・使いやすいと感じるか・また使いたいと思えるかなど
②ユーザビリティ評価	操作性や達成度を数値的に測る	・操作をミスなく完了できたか・どのくらいの時間でゴールに到達できたか

この二軸の評価を組み合わせることで、単に「便利そう」という印象だけでなく、実際の操作性まで含めた総合的な改善点を明確にできます。そして評価結果をもとに再度改善を繰り返すことで、完成度の高いUI/UXが実現できるのです。

アプリのUI/UXを改善するポイント

アプリのUI/UXを改善する3つのポイントを紹介します。

ポイント①ユーザーの理解を優先し実証的に改善する

アプリ改善は「ユーザーをどれだけ理解できるか」にかかっています。ペルソナ設計やユーザーインタビューを通じて、「誰に」「何の価値を」「なぜ提供するのか」を明確にすることで、アプリの方向性がブレずに済みます。また、机上で考えるだけでは不十分で、プロトタイプを実際にユーザーに使ってもらい、その操作感や不満点を観察することで、想定していなかった課題が明らかになります。
実際の声や行動に基づいて改善を繰り返すことで、机上の空論ではなく実証されたUI/UXが作れます。

ポイント②シンプルで明快なデザインを追求する

アプリの画面に情報や機能を詰め込みすぎると、ユーザーは「どこを押せばいいのか」「次に何をすればよいのか」が分からなくなり、結果として離脱につながります。
そのため「1画面1タスク」を意識し、必要以上の要素を並べないことが重要です。長い入力フォームは分割したり、ステップごとに必要な情報だけを表示したりすることで、ユーザーの認知負荷を減らせるのです。
複雑な機能を持つアプリであっても「迷わず操作できるか」という一点を優先して設計することで、初心者でも直感的に扱える優れたUXにつながります。

ポイント③一貫性・アクセシビリティを確保する

アプリ全体のUI要素が統一されていると、ユーザーは一度学んだ操作を他の画面でも迷わず活かせるため、スムーズに利用できます。フォント、色、ボタンの形や配置がバラバラだと直感的に操作できず混乱を招きますが、一貫したデザインはユーザーに安心感を与えられるのです。
また、操作に応じたフィードバックを取り入れることで、ユーザーは「正しく操作できた」と理解できます。結果としてアプリの評価や利用率向上にもつながります。

UI/UXを改善した事例

ここでは、アプリのUI/UXを改善した事例について3社紹介します。

企業名	課題	改善内容	効果
Uber	機能追加によるUI/UXの複雑化でユーザー体験が劣化	・ホーム画面から配車までのステップを見直し、不要なタップや確認画面を削除	・配車完了までの平均タップ数を20％削減
スターバックス	ドリンクカスタマイズ画面が分かりにくい	・カスタマイズ画面にアレルギー情報やトッピング選択を統合し、プレビュー機能を導入	・注文完了率が15％向上
株式会社リクルート	転職者が職務経歴書の作成過程で迷いやすく、入力や操作に時間がかかる	「初めてでも迷わず作成できる」コンセプトを設定し、プロトタイプ検証を実施。	・転職者がストレスなく経歴書を作成できるようになった

事例①Uber

Uberは当初の「ワンタップで配車できる魔法」のようなシンプルさが、多数の機能追加によって複雑化し、ユーザー体験が劣化してしまった問題を抱えていました。そこでプロジェクトチームは、ユーザーの最も基本的な行動である乗車依頼にフォーカスし、改善を行いました。
まず、アプリのホーム画面から配車までのステップを徹底的に見直し、不要なタップや確認画面を削減して操作を最速化したほか、車種選択や支払方法の切り替えを直感的に行えるスライダーメニューを導入します。また、待機時間や到着予測の表示をリアルタイムで更新し、ユーザーが配車状況を一目で把握できるようにすることで、安心感と操作性を大幅に向上させました。
この再設計により、配車完了までの平均タップ数が20％削減され、ユーザー満足度が顕著に向上しています。

事例②スターバックス

スターバックスのモバイルアプリは、グローバルでの圧倒的なブランド力の一方で、ユーザーの不満も多く寄せられていました。

ログイン時の操作の煩雑さ
ドリンクカスタマイズ画面の分かりにくさ
注文処理中のエラー発生による決済離脱

そこで、デザインチームはまずユーザーの利用動向を分析し、特に48％のユーザーが非乳製品ミルクを選択する傾向に着目します。カスタマイズ画面ではアレルギー情報やトッピング選択をシームレスに行えるインターフェースを採用するとともに、ドリンクプレビュー機能を搭載し、選択内容の視覚的確認を可能にしました。
注文フローでは最終確認画面のレイアウトを整理して情報の優先度を見直し、アニメーションを用いたガイドで次のアクションを明確化します。これにより、注文完了率が15％向上し、アプリストアの評価も3.8へと改善されました。

事例③株式会社リクルート

株式会社リクルートが提供する「職務経歴書作成Webサービス」では、利用者が初めて使う際に入力方法や操作の流れが分かりにくく、途中で迷ってしまうことが多く見られました。特に転職活動を進めるユーザーは、限られた時間の中で効率的に書類を完成させたいというニーズがありながら、操作性の悪さが障壁になりました。
そこでリクルートは「初めてでも迷わず作成できる」というコンセプトを設定し、プロトタイプを用いた検証を重ねながら改善を実施します。行った施策は以下の通りです。

ペルソナ分析を通じて利用者の課題を洗い出し
ワイヤーフレームを用いた要件整理で構造を見直し
スマートフォンでの利用を前提としたUI設計とアトミックデザインの導入

その結果、操作のしやすさが大幅に向上し、転職者が安心して利用できるサービスへと進化し、利用意欲の向上につながりました。

アプリのUI/UX改善はバルテス・イノベーションズまで

UI/UX改善は単なるデザイン刷新ではなく、ユーザー理解に基づく調査・設計・検証を繰り返し、継続的に成果を生み出すプロセスです。しかし、自社だけで体系的に進めるのは難しく、専門知識や客観的な視点が欠かせません。

バルテス・イノベーションズでは、ユーザーリサーチからプロトタイプ検証、開発フェーズにおける品質保証までワンストップで支援し、事業成果に直結するUI/UX改善を実現します。アプリやWebサービスの離脱率改善や顧客満足度向上に本気で取り組みたい方は、お気軽にご相談ください。
UI/UX改善ソリューション

The post アプリのUI/UX改善の方法を4つのステップで解説！成功するコツや事例も紹介 first appeared on Valtes Innovations.

モバイルアプリ開発費用の内訳は？失敗しないポイントを解説

上西渡累 — Thu, 11 Sep 2025 09:36:59 +0000

スマートフォンの普及により、モバイルアプリを通じたサービス提供は一般的になっています。開発を検討する際に最初に気になるのは費用面です。担当者のなかには「自社アプリを作りたいがコストが心配」という方も少なくありません。

本記事では、モバイルアプリ開発にかかる基本的な費用と、依頼先の選び方で失敗しないためのポイントを紹介します。開発を検討している方は参考にしてください。

モバイルアプリ開発にかかる主な費用

モバイルアプリの開発にはさまざまな費用が発生しますが、大まかに「人的コスト」「物的コスト」の2種類があります。それぞれについて、具体的に見ていきましょう。

人的コスト

モバイルアプリの開発には、要件定義から設計、コーディング、テスト、保守運用にいたるまで、さまざまな人々の協力が欠かせません。エンジニアやデザイナー、テスト担当者など、各担当者の作業に応じて発生する費用が人的コストです。

人的コストは基本的に「単価×工数（作業時間）」で算出されます。当然ながら、工数が増大するほど人的コストも膨らみます。単価は、各作業者のスキルや経験によっても変わります。たとえば、高度な技術を扱えるエンジニアほど単価は高くなるでしょう。

物的コスト

人的コストとは別に、物理的な環境や機材などの確保・利用にともない発生するのが物的コストです。たとえばモバイルアプリを稼働させるサーバーのレンタル費用、開発に使用するツールやフレームワークのライセンス料などが挙げられます。

特にモバイルアプリ開発の場合、各OSに対応した開発やテストのために実機や検証環境の調達費用が欠かせません。また、完成したモバイルアプリを公開する場合、アプリストアへの登録費用も発生します。こうした費用も含めて物的コストを見積もりましょう。

モバイルアプリ開発の費用を決める主な要素

モバイルアプリ開発にかかる費用は、さまざまな要素に左右されます。モバイルアプリ開発の費用を決める5 つの主な要素について知っておきましょう。

開発規模・開発期間

開発費用を大きく左右するのが開発規模・開発期間です。規模が大きくなるほど期間も長くなるため、両者は密接に関わっています。開発規模の増大・開発期間の延長は工数増加に直結し、人的コストが膨らむ要因となります。月額課金のツールなどを使っている場合は、物的コストも増大します。

開発規模は、実装する画面数や機能数、機能の複雑さで決まります。たとえば、パスワード入力だけのシンプルなログイン機能と、SMSコードなどを併用する二要素認証を備えたログイン機能では、後者の方が開発規模は大きくなるでしょう。

使用技術

モバイルアプリ開発で採用する技術も費用に影響します。影響する費用は、主に「技術の使用料（ライセンスなど）」と「技術実現のための人件費」の2つです。高度な技術や革新的な技術を使うほど、いずれも費用は増大しやすくなります。

たとえば、GPSにより位置情報を活用できる機能を開発する場合、地図サービスのAPI利用料や、位置情報を正確に処理するための高度な開発が必要です。高度な技術はモバイルアプリの完成度や利便性を高めますが、費用も高くなる点は覚えておきましょう。

開発手法（コーディング方法）

開発手法も費用に影響します。特に、モバイルアプリのコーディング方法に着目した場合の代表的な開発手法は、次の3つです。

開発手法	概要
スクラッチ型	ゼロからコードを書き上げて開発する手法。自由度は高い反面、最も開発規模・開発期間が膨らみやすい。
ローコード型（ノーコード型）	パッケージや、専用開発プラットフォーム専用ツールを活用し、手動コーディングの作業を一部（または全て）削減する手法。効率性は高いが、自由度は低い。
複合型	スクラッチ型とローコード型を組み合わせ、自由度と効率性のバランスを取る手法。

自由度を追求すれば開発のハードルは上がり、効率性を追求すれば機能に制約が生じます。自由度と効率性のトレードオフを考慮して開発手法を選びましょう。

開発手法（プラットフォーム対応方法）

モバイルOSとしてはAndroid・iOSの2種類が代表的です。多くの場合、双方に対応したモバイルアプリを開発することになるでしょう。各プラットフォームへの対応方法に着目した場合、次の2つの開発手法があります。

対応方法	概要
ネイティブ開発	各モバイルOS専用の言語で個別に開発する手法。AndroidではJavaやKotlin、iOSではSwiftなどの言語を使用する。各モバイルOS固有の機能を活用できるが、別々にコードを作成する必要があり、開発規模・開発期間が膨らみやすい。
ハイブリッド開発（クロスプラットフォーム開発）	Android・iOSの双方に対応可能なフレームワークを使用し、1つのコードで両OSに対応したモバイルアプリを開発する手法。開発効率は高いが、一部モバイルOS固有の機能に制約がある。

モバイルOSごとの利用体験を追求する場合はネイティブ開発、効率性や費用を重視する場合はハイブリッド開発が適しています。

利用方法

完成したモバイルアプリの利用方法も、費用を決める大切な要素です。特に「社内利用」と「一般公開」では、費用が大きく変わってきます。基本的に、利用範囲が狭いほど費用は低く抑えやすいです。

一般ユーザーに公開する場合、「App Store」や「Google Play」への登録・更新費用が発生します。また、利用者が増えれば、サーバーの保守運用やユーザー対応などのコストも増大するでしょう。社内利用のみであれば、このような追加費用は抑えられます。

モバイルアプリ開発で失敗しないためには

モバイルアプリ開発は、費用を抑えたからといって成功するとは限りません。モバイルアプリ開発で失敗しないための大切なポイント2つを押さえておきましょう。

ユーザー体験を大切にする

特に一般公開するモバイルアプリ開発の場合、ユーザー体験（UX）を大切にしましょう。UXとは、アプリの利用を通して得るすべての経験を指します。見た目の美しさ、操作のしやすさ、情報の分かりやすさなど、あらゆる面で満足させるための設計が不可欠です。

開発費用の削減を優先してユーザー体験がおろそかになると、結局は利用者が離れてしまい、ビジネスとしての収益につながりません。成功するアプリを作るためには、開発の初期段階からUXを徹底的に考慮した設計を行いましょう。

リリースや保守運用も考慮する

モバイルアプリ開発は、完成して終わりではありません。モバイルアプリ完成後のリリースや保守運用も見据えましょう。
一般公開する場合、アプリストアへの登録・更新作業が必要です。また、社内利用・一般公開を問わず、継続的な保守運用が欠かせません。OSやサーバーなどの定期的なアップデートや、利用者からのフィードバック対応といった体制を整えることが大切です。

モバイルアプリ開発の依頼先を選ぶ際のポイント

高品質なモバイルアプリを効率的に開発するために、外部の開発会社に依頼するのは有力な選択肢です。しかし、依頼先選びを誤ると、期待したアプリが完成しなかったり、思わぬトラブルにつながったりすることも考えられます。

ここでは、モバイルアプリ開発の依頼先を選ぶ際のポイントについて解説します。

サポート範囲

依頼先を選ぶ際は、どこまでサポートしてもらえるかを必ず確認しましょう。開発だけでなく、リリース後のアプリストア公開や保守運用まで一貫して対応してくれる開発会社もあります。反対に、後々に問題が発生しても十分なサポートを受けられないケースもゼロではありません。自社の負担を減らしたい場合は、サポート範囲が広い開発会社を選ぶと良いでしょう。

開発実績

依頼先の開発実績は、モバイルアプリの品質やデザイン性を判断するうえで大切な情報です。開発実績を確認し、自社が期待するモバイルアプリを実現できる開発会社か確かめましょう。特に、自社と同じ業種や似た規模のモバイルアプリ開発実績があると心強いです。同種のモバイルアプリ開発経験が豊富だと、ノウハウが蓄積されているため、大きな失敗を避けられるでしょう。

各工程の見積もり金額

複数の企業から見積もりを取る際は、全体の金額だけでなく、開発工程ごとの内訳を比較しましょう。全体の費用が安くても、重要な工程の金額が不自然に低い場合、注意が必要です。たとえば設計の費用が安すぎると、ドキュメントが不十分で保守運用が難しくなったり、後々に大きな問題が判明して多大な手戻りが生じたりするケースもあります。

また、モバイルアプリの不具合は、発見するタイミングが遅いほど修正費用が膨らみます。テスト段階で見つかる不具合の修正費用は、市場に出てから見つかる場合と比べて大幅に安価です。特に、設計の段階で問題点を見つけると、後の修正コストを1/10～1/100程度に抑えられます。

このように、将来的なことを考えると、ただ費用が安いから良いとは限りません。開発費用が多少増大したとしても、確実にモバイルアプリの品質を保証してくれる開発会社を選ぶほうが、潜在的な追加費用を抑制できます。

アプリ開発費用参考リンク:https://pentagon.tokyo/app/1997/

まとめ

今回は、モバイルアプリ開発の費用をテーマにお伝えしました。モバイルアプリ開発の費用には人的コストと物的コストがあり、開発規模や開発期間、使用技術、開発手法、利用方法などが費用に影響します。費用を抑えたい場合は、何に費用がかかるのかを把握しておきましょう。
ただし、費用が安ければ成功するとは限りません。将来的な不具合を防ぐには、品質を確保し、信頼できる成果を提供できる開発会社を選ぶことが重要です。

バルテス・イノベーションズは、開発初期からユーザー体験を重視し、高品質なモバイルアプリを提供しています。ハイブリッド開発で効率を高めながら、厳格な品質基準とテストを実施することで、リリース後の不具合を最小限に抑えています。高品質なアプリを目指す方は、ぜひお問い合わせください。

The post モバイルアプリ開発費用の内訳は？失敗しないポイントを解説 first appeared on Valtes Innovations.

リバースエンジニアリングとは？目的や手法、活用されるシーンを紹介

上西渡累 — Mon, 25 Aug 2025 02:03:58 +0000

「ソフトウェアの仕組みや構造が分からない」といったシーンで有効な手法が「リバースエンジニアリング」です。リバースエンジニアリングを行いたいものの、具体的な実施方法や使うべきソフトウェアなど、疑問を抱えている方も多いのではないでしょうか。

今回は、「リバースエンジニアリングとは何か」をテーマに、基本をまとめてお伝えします。リバースエンジニアリングに役立つソフトウェアも紹介しますので、ぜひ参考にしてください。

ソフトウェアへのリバースエンジニアリングとは

リバースエンジニアリングとは、既存のソフトウェアを分析して、その仕様や設計を明らかにする手法です。

通常のソフトウェア開発では、仕様書や設計書に基づいて開発が進みますが、これらの文書が存在しない、または確認できない場合もあります。そうしたときに有効なのがリバースエンジニアリングです。

この手法は、通常の「設計から開発」への流れとは逆に、完成したソフトウェアを出発点として、内部のコードや構成から仕様や設計の意図を読み取ります。

つまり、完成済みのソフトウェアをもとに仕様や設計を再構築するのが、リバースエンジニアリングの目的です。

ソフトウェアに対するリバースエンジニアリングの主な目的

ソフトウェアに対するリバースエンジニアリングは、さまざまな目的で行われています。ここでは、リバースエンジニアリングの4つの目的について見ていきましょう。

属人化の解消
コードの品質向上
脆弱性の特定
技術的な調査

属人化の解消

既存のソフトウェアを継続的に運用するうえで、属人化（特定の担当者にしか対応できない状態）は大きな課題です。リバースエンジニアリングは、その解消に有効な手段です。

長年運用されたシステムでは、修正や拡張が繰り返され、最新の仕様や設計を反映した文書が残っていない場合があります。その結果、担当者以外が全体像を把握しにくくなり、引き継ぎや作業分担に支障をきたすこともあります。

リバースエンジニアリングによって、現行のソフトウェアに即した仕様書や設計書を整備すれば、新たな担当者でも短期間でシステムを理解しやすくなります。属人化の解消と業務の標準化にもつながるでしょう。

コードの品質向上

リバースエンジニアリングは、コードの品質向上にも役立ちます。

内部構造が可視化されていない状態では、冗長な記述や構造的な問題に気づきにくくなります。特に、長年にわたって調整が繰り返されたシステムでは、コードが複雑化し、保守が難しくなる傾向があります。

リバースエンジニアリングを通じて構造を把握すれば、重複処理や非効率なアルゴリズムなど、潜在的な問題を見つけやすくなります。

問題を改善することでコード全体の品質が向上し、保守にかかる負担やコストの削減にもつながります。

脆弱性の特定

リバースエンジニアリングは、ソフトウェアに潜む脆弱性（セキュリティ上の弱点）の特定にも有効です。近年はサイバー攻撃の脅威が高まり、ソフトウェアの安全性確保が重要になっています。

特に、古い技術で構築されたレガシーシステムでは、新たな脆弱性に対応できていない場合があります。その構造や設計を明らかにすることで、脆弱性への対処が可能になります。

技術的な調査

これまで紹介した3つの目的は、主に自社内のソフトウェアに対するリバースエンジニアリングでした。一方で、他社製品やオープンソースソフトウェアを対象とした技術調査の目的でも、リバースエンジニアリングが行われるケースはあります。

外部のソフトウェアでは、詳細な仕様や設計が公開されていない場合が珍しくありません。そこで、リバースエンジニアリングによって内部の仕組みや構造を分析すれば、使われている技術について把握できます。
ただし、特定の企業や個人が開発・提供しているシステムやサービスに対してリバースエンジニアリングを行う場合は注意が必要です。
利用規約で禁止されているケースも多く、著作権の侵害につながる恐れがあります。実施前には必ず利用規約やライセンス条件を確認し、規約違反とならないよう十分に配慮して進めましょう。

ソフトウェアに対するリバースエンジニアリングの手法

リバースエンジニアリングの手法は、主に「静的解析」と「動的解析」の2つに大別されます。それぞれの手法について見ていきましょう。

静的解析

静的解析とは、ソフトウェアを実行せずにコードの内容を解析する手法です。主にソースコードやバイナリファイル（実行可能ファイル）を解析しやすい形に変換し、そこから処理の流れや構造を読み取ります。

具体的な方法としては、逆アセンブル（機械語をアセンブリ言語に変換する手法）や、逆コンパイル（バイナリファイルを元のコードに近い形へ戻す手法）などがあります。いずれも、実際の動作をともなわずに解析できる点が特徴です。

ただし、逆コンパイルなどで生成したソースコードは、可読性が著しく低いケースが少なくありません。この場合、人間が解読することは容易ではなく、リバースエンジニアリングには高度なスキルや経験、多くの労力が求められます。結果として、作業期間やコストが増大する場合もある点に注意が必要です。

静的解析は、コードの品質調査や技術的な調査など、さまざまな目的で行われます。

動的解析

動的解析は、ソフトウェアを実際に動作させ、その挙動から内部の構造や処理を解析する手法です。入力データに対する出力データの変化や、実行時のメモリ使用状況・CPU状態など、ソフトウェアの挙動を詳細に調べます。

具体的な方法としては、デバッギング（専用のデバッガを用いてソフトウェアの詳細な動作を追跡する手法）やネットワーク解析（外部とのネットワーク通信を監視・分析する手法）などがあります。

動的解析は、ソフトウェアを動かさないと発見が難しい問題も検出できる点が特徴です。脆弱性の検出やマルウェアの挙動確認といったセキュリティ分野でも広く行われています。

リバースエンジニアリングに役立つソフトウェア3選【フリー／有料】

リバースエンジニアリングを行う際には、専用の解析ソフトウェアが欠かせません。ここでは、静的解析や動的解析に役立つ代表的なツールを3つ紹介します。

JD-GUI

「JD-GUI」は、多くのシステムに採用されている「Java」で開発されたソフトウェアの逆コンパイルに特化したツールです。クラスファイル（*.class）やJARファイル（*.jar）を元のJavaプログラムに近い形で復元できます。

名前の通り、GUI（視覚的な操作画面）を備えているため、慣れていない方でも直感的に操作しやすいのが特徴です。Javaを扱うシステム開発において、属人化の解消を目指すケースなどで役立つでしょう。

SonarQube

「SonarQube」は、「Java」「C#」「Python」といった幅広いプログラミング言語に対応している静的解析ツールです。コードに潜んだバグや脆弱性、保守性を損なう問題点などを自動的に検出・可視化します。

「COBOL」のような昔ながらの言語にも対応しているため、幅広い開発現場で活用されています。ただし、静的解析を行うためには、事前に変換されたコードが必要です。そのためバイナリファイルを解析したい場合には、逆アセンブルや逆コンパイルに対応した別のツールを併用する必要があります。

Jitera

「Jitera」は、AI（人工知能）によりソフトウェア開発の自動化・効率化を支援するツールです。コードの自動生成といった通常の開発支援機能に加え、既存コードから設計書を生成するといったリバースエンジニアリング寄りの機能も備えています。

設計書が存在しない、いわゆるブラックボックス化したシステムでも、コードを通して全体構造を迅速に把握できます。「コードは残っているが、仕様が不明」といった場面で活用しやすいツールです。

まとめ

リバースエンジニアリングとは、既存のソフトウェアを分析し、その仕様や設計を明らかにする手法や技術のことです。システムの可視化による属人化の解消、コードの品質向上、脆弱性の特定、技術調査など、さまざまな場面で活用されています。

リバースエンジニアリングには、専用のソフトウェアを活用することが一般的です。ただし、正確に進めるためには専門知識や経験が求められ、ノウハウがないと対応が難しいケースもあります。

バルテス・イノベーションズでは、専門エンジニアによる高品質なリバースエンジニアリングサービスを提供しています。社内に適任者がいない、進め方が分からないといった場合は、ぜひご相談ください。

The post リバースエンジニアリングとは？目的や手法、活用されるシーンを紹介 first appeared on Valtes Innovations.

DXの成功事例5選！事例に共通する推進ポイントをわかりやすく解説

上西渡累 — Mon, 18 Aug 2025 01:09:02 +0000

現在のビジネス環境において、「DX（デジタルトランスフォーメーション）」は、企業の競争力維持と成長に欠かせない戦略となっています。
「DXという言葉は聞いたことがあるが、何を目指すのかよくわからない」
「自社でもDXを進められるのか不安」
このように、DXの必要性を感じながらも、具体的な進め方に悩む経営層は少なくありません。

本記事では、DXの定義や現状を整理し、具体的な成功事例を5つ紹介したうえで、共通する推進のポイントをわかりやすく解説します。

DXとはそもそも何か？定義やデジタル化の違いをわかりやすく解説

DXの重要性が強調される一方で、その本質を正しく理解していないケースも見られます。ここでは、DXの定義と、混同されやすい「デジタル化」との違いを解説します。

DXの定義

経済産業省はDX（デジタルトランスフォーメーション）を以下のように定義しています。

“企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること。”

出典：デジタルガバナンス・コード3.0 ～DX経営による企業価値向上に向けて

DXは、単にITツールを導入することではなく、デジタル技術を活用して顧客に新たな価値を提供し、ビジネスモデル全体を変革する取り組みです。

その推進には、業務プロセスだけでなく、組織や企業文化など、あらゆる側面の見直しが求められます。

DXとデジタル化・デジタライゼーション・デジタイゼーションの違い

DXを正しく理解するために、混同されやすい「デジタル化」との違いを下表で確認してください。なお、デジタル化は「デジタイゼーション」と「デジタライゼーション」に分類されます。

項目		内容	例
DX		デジタル化を基盤に、ビジネスモデルや企業文化を抜本的に変革し、新たな価値を創出する	デジタル化された社内データを専門的に分析し、新たな顧客層をターゲットにしたサービスを創出する
デジタル化	デジタライゼーション	デジタル技術を活用して業務プロセスを効率化する	ERPシステムを販売部で導入する
デジタル化	デジタイゼーション	アナログデータをデジタルデータへ変換する	紙の書類をPDF化する

DXはデジタル化を包含しつつ、より戦略的で全社的な変革を目指す点が異なります。

日本企業におけるDXの現状

日本企業のDX推進は遅れているといわれることがあります。総務省の調査によると、DXの前段階であるデジタル化の進行率は、米国・ドイツ・中国が70〜90％に達している一方、日本は約50％にとどまっています。

図1: デジタル化の取組状況（各国比較）

しかし、確実に進展していることが伺え、2019年以前では29%だった実施率が、2024年には49%になりました。

図2: デジタル化の取組状況（日本：企業規模別比較）

企業規模別に見ると、大企業は76％が取り組んでいる一方で、中小企業は30％にとどまり、実施状況に大きな差があります。

出典：総務省｜令和7年版情報通信白書

DXの成功事例5選

ここでは、実際に企業がDXを推進し、成果を上げた具体的な事例を紹介します。業種や規模の異なる事例を取り上げるため、自社に活かせるヒントが見つかるでしょう。

1.バルテス・イノベーションズが手掛けた製造業の事例

IoT（Internet of Things）を活用したDX事例として、「極東開発工業株式会社」様の輸送用特装車の保守メンテナンス体制を根本から変革し、圧倒的な競争優位性を築いた取り組みがあります。
特装車は特殊部品を多く含み、ユーザー自身による保守負担も大きいため、従来の保守リソースでは限界がありました。
そこで、IoT技術を駆使した専用アプリを開発し、スマートフォンのBluetooth通信で車両と連携させ、必要なデータの即時閲覧や保守部品の一元管理を可能にしました。
さらに、車両の利用ログをクラウドで詳細に収集・分析し、走行距離に応じた最適な保守タイミングを自動通知。属人的だった保守工数を激減させ、人手不足という課題を乗り越えるだけでなく、飛躍的な生産性向上を実現させました。

結果として機械の長寿命化を達成し、業界内における圧倒的な競争優位性を確立しています。

2.飲食業の事例

外食業界は競争相手の激化や人手不足による人件費の高騰によって深刻な状況が続いており、ビジネスモデルや顧客体験の変容を通じた差別化・ブランド化が急務です。
例えばすかいらーく系列の店舗では猫型の配膳ロボット「Berabot（ベラボット）」を導入することにより、ホールスタッフ業務の負担軽減のみならず、猫型ロボットを見に行くという体験価値の拡張を促しています。

また多くのチェーン店で導入が進むモバイルオーダーは、顧客の注文体験の刷新により、顧客の手間の軽減を通じて時間短縮やリピート率の向上に役立っています。
人手不足や費用の高騰と聞くと、どうしても短期的な収益に目が行きがちですが、差別化・ブランド化といった長期的な観点での施策が顧客からの支持を集めています。

3.物流業界の事例

ヤマト運輸が展開する個人向け会員サービスの「クロネコメンバーズ」では、荷物の配送状況の確認、受け取り日時・場所の指定、置き配指示などがオンラインで可能です。

従来は不在通知を受けて再配達を依頼する受け身の対応が主流でしたが、クロネコメンバーズでは顧客自らが配送プロセスを事前にコントロールでき、生活行動が能動的に変化しました。

配達員にとっては配送の効率化が進み、再配達率の低減に貢献しています。

4.自治体の事例

宮崎県都城市では、行政サービスの利便性向上を目的に、LINEを活用した行政DXを推進しています。

住民はLINE上でゴミの分別方法や収集日程を確認でき、子育て支援や災害情報など一元的にあらゆる情報が受け取れます。
従来は電話や窓口で行われていた行政との接点が、日常的な連絡手段であるLINEに置き換わった点が特筆すべき点です。
問い合わせ対応の効率化が進み、人的リソースの適正配置が可能となりました。
行政と住民とのコミュニケーションの形を再定義した地域行政の実効的なDX事例です。

5.サービス業の事例

大手コンビニチェーン「ファミリーマート」では、DXによって店舗運営の革新を進めています。スマートフォン向けアプリを基盤に、顧客データを活用したパーソナライズ情報の発信や無人店舗の決済システム導入など、利便性向上に向けた施策を展開しています。

アプリにはキャッシュレス決済やクーポン、複数のポイント連携など従来はバラバラに管理されていたサービスが統合され、アプリ一つで買い物から支払い、ポイント利用、クーポン利用までを完結できるようになりました。

レジでの待ち時間短縮や利便性向上につながり、満足度も上がっています。
店舗側はレジ業務の省人化で運営コストを削減でき、顧客データの活用で需要予測や陳列改善が実効的になりました。
顧客中心のサービス強化で競争力を高めるとともに、デジタル人材の育成にも力を入れ、全社的な変革を推進しています。

DX成功事例から見える共通のポイント5つ

DXの成功事例には、共通するポイントがあります。ここでは、今回紹介した事例に共通して見られる、推進時に重視すべき5つのポイントを解説します。

1.経営層の強いコミットメントと明確なビジョン設定

成功事例では、経営層がDXの目的を明確にし、全社を巻き込んで主導しています。従業員の意識を統一し、現場の改善にとどまらず、経営戦略として取り組む姿勢が求められます。

2.顧客中心の価値再定義（顧客体験の再設計）

DXの目的は「顧客への新しい価値提供」です。顧客体験（CX）の向上は、ニーズを深く理解した新たな価値創出につながります。データ分析やAIを活用したパーソナライズされたサービス提供や、シームレスなオムニチャネル体験の構築が重要です。

顧客からのフィードバックを取り入れながら、継続的に改善していく顧客視点によるビジネスモデルの再設計を通じて、競争優位性を確立できるでしょう。

3.データを活用した意思決定とサービス設計

顧客データを活用したサービス改善により、成果が上がっています。DXは業務効率化にとどまらず、顧客へ新たな価値を提供することが重要です。データ分析基盤を整備することで、データに基づいた意思決定が進み、競争力の強化につながります。

4.部門横断の連携と組織文化の変革

DXは部門間の壁を越えた連携が欠かせません。特定の部署だけで完結するものではなく、すべての部門が連携する必要があります。部門間の壁を取り払い、共通の目標に向かう文化や連携の変革は、DXの成功要因です。

また、失敗を恐れない挑戦できる文化の構築も、変革を持続させる原動力となります。

5.継続的な学習と変化への適応力

DXは継続的で柔軟な変革です。技術や市場トレンドは常に変化しており、継続的に学習し変化に適応を続ける姿勢が重要です。小さな失敗から学び、迅速な改善を繰り返す「アジャイル」なアプローチは有効です。

また、業界やトレンドの変化を敏感に捉えながら、全社員がリスキリングや新たなスキル獲得に努めることで、組織全体の適応力を高めます。

DX化はバルテス・イノベーションズにご相談を

本記事では、DXの成功事例と共通する推進ポイントを紹介しました。企業の成長にDXは欠かせませんが、自社のリソースだけで進めるのは難しい場合もあります。
そのようなときは、外部の専門家と連携することで、短期間での成果につながりやすくなります。

バルテス・イノベーションズは、業界理解と技術力を兼ね備え、戦略から実行まで伴走できる企業であり、幅広い業種のお客様からご支持をいただいております。

「何から始めればよいかわからない」
「DXの全体戦略から現場の実装まで一括で支援してほしい」

といったご相談・お悩みがある場合は、まず無料相談からお気軽にお問い合わせください。
DXコンサルティングサービス｜バルテス・イノベーションズ株式会社

The post DXの成功事例5選！事例に共通する推進ポイントをわかりやすく解説 first appeared on Valtes Innovations.

Reports - Valtes Innovations

AIエージェント、生成AIと何が違うのか 日本企業3社に学ぶ「ケンタウロス型」の始め方

「AIエージェント」とは何か、生成AIとの3つの違い

生成AIは「聞けば答える道具」、エージェントは「頼めば動く担当者」

人間とAIの分業パターン、3つの類型

現在最も普及しているのはケンタウロス型

「丸ごと自動化」が難しい理由と、ケンタウロス型が選ばれる根拠

全自動が難しい3つの壁

人間の役割を「決める人」に絞り込む設計

人は例外時だけ対応する運用へ

サイバーエージェント・パナソニックコネクト・三菱UFJ銀行、3社の役割分担と効果

広告クリエイティブ×制作量4.5倍、サイバーエージェント「極予測AI」

全社展開×年間44.8万時間削減、パナソニックコネクト「ConnectAI」

融資稟議書ドラフト×実証段階、三菱UFJ銀行×Sakana AI

自社の業務から始める3つの判断軸

AIに委任しやすい業務の特徴

AIに委任する範囲と人間が握る役割の切り分け

チャット型から試してエージェント型へ移行する段階設計

人が判断を握り、AIが実行を担う

参考出典

生成AIの料金が定額から従量へ、2026年4〜6月の経緯を年表で整理【2026年6月時点】

4月の決壊点、6月の答え合わせ

流れは3行で

詳細年表

人間がチャットで使う前提だった定額制

Fable 5の価格が示す知能の価格分化

6月15日以降に控える3つの変更

変わったのは構造、問われるのは自社の対応

Claudeの従量課金移行で生成AIの料金はどう変わるか——「直撃する自動化」の切り分けとコスト管理3ステップ【2026年6月時点】

定額のまま使える利用、従量に変わる自動化

人の対話は定額のまま、機械の自動実行は従量へ

無風・クレジット消費・直撃の3分類

読み進めるための用語4つ

影響が出る個人プラン、維持される法人契約

GitHub Copilot

Anthropic Claude

Google Gemini

自社の影響額を見積もる式と考え方

式の中で効くのは呼び出し回数

提供元自身が認めた想定超え

様子見と両立する棚卸し

月曜から始めるコスト管理3ステップ

Step1 使用量のモニタリング

Step2 処理の重さに応じたモデル使い分け

Step3 ROI管理

棚卸しチェックリストと、属人化という次の壁

個人の工夫を業務プロセスへ

なぜあなたの会社のDXは進まないのか｜72社の現場実態調査レポート

1. 調査概要

参加者プロフィール

2. データが示す実態 ─ 72社の現場で何が起きているのか

発見① 「何から始めるか」で止まっている企業が大多数

発見② DXが「これから／結果がまだ出ていない」企業が58%

発見③ 「電子化＝DX」という誤解が根強い

3. なぜDXは「電子化」で終わるのか

「よくあるストーリー」

DXの定義に立ち返る

3段階のフレームワークで自社位置を確認する

4. DXの最初の壁 ─ 現状が見えないから動けない

立場別に見える「リアルなペイン」

5. なぜ「現状の可視化」は行われないのか

① レガシーシステムのブラックボックス化

② 業務プロセスの属人化

③ IT部門だけでは業務実態を把握しきれない

④ ベンダー提案が「ツール前提」になっている

⑤ 可視化のスコープが絞れない

6. 現状可視化からDX、そしてAXへ ─ 3つのステップ

7. バルテス・イノベーションズが提供できること

支援実績

まとめ

DXの現状整理、まずご相談ください

本レポートについて

レガシーシステムとは？脱却が進まない要因と3つの脱却方法を解説【チェックリスト付き】

レガシーシステムの定義

①技術的観点からの定義

② 経営的観点からの定義

レガシーシステムを放置する危険性

レガシーシステムかどうかのチェックリスト

レガシーシステムの脱却が進まない要因・問題点

要因①IT人材の不足

AIエージェント、生成AIと何が違うのか　日本企業3社に学ぶ「ケンタウロス型」の始め方