こんにちは。ACS事業部の越川です。
今日は、AI活用を推進するエンジニアとして、自分自身の思い込みに気づいた話を書きます。
結論から言います。AI活用の推進はエンジニアの仕事だと、無意識に思い込んでいました。
- きっかけはブログのサムネイル議論だった
- 私はAI活用をエンジニアが主導するものだと思い込んでいた
- AI設計とAI活用は別物
- この思い込みは私だけではなかった
- エンジニアファーストの落とし穴
- これはPlatform Engineeringと同じ構造
- 各部署の専門家がAIを使える組織へ
- あなたの組織ではどうですか？
- 参考資料
- ACS 事業部のご紹介
きっかけはブログのサムネイル議論だった
弊社が運用しているAPC技術ブログですが、3月の投稿数が前月比で倍増しました。AIワークフローの仕組み化が効いて、量は出せるようになりました。しかし、アクセスデータを分析してみると、同じ品質の記事でもPVに大きな差があることに気づきました。
「データで見たい」と思った瞬間、エンジニアの自分はすぐに手を動かしました。Pythonでアクセスデータを読み込み、ブログのAtomフィードから著者情報を取得し、各記事のサムネイル画像をスクレイピングして、著者別にフィルタできるランキングツールを1時間で作り上げました。 ブラウザでCSVをドロップするだけで、全記事のランキングがサムネイル・公開日・著者付きで一覧表示されます。このツールは社内でGitHubリポジトリとして公開し、他のメンバーもすぐに使える状態にしています。
エンジニアの技術力を使えば、分析環境はこの速度で手に入ります。しかし、ツールで自分の記事を並べてみて見えてきた課題は、技術力では解決できないものでした。
原因はサムネイルとタイトルの設計にありました。Webマーケティング経験のあるメンバーからも「サムネイルはタイトルと同等以上にクリック判断に影響する」「AI生成イラストと分かるサムネイルはスルーされるリスクがある」と指摘を受けました。
なるほど、サムネイルは重要だ。ならば広報にサムネイル作成を依頼しよう——最初はそう考えました。しかし、メンバーから「気軽に投稿するブログに毎回広報が出てくるのは現実的ではない」と指摘されます。もっともな話です。
そこでふと思いました。広報自身がCanva AIやChatGPTを使えば、テンプレートに沿ったサムネイルを自分で量産できるのではないか。
この瞬間、自分の中の前提が崩れたのを感じました。
私はAI活用をエンジニアが主導するものだと思い込んでいた
振り返ると、AIに関わる話が出るたびに、エンジニアである自分が設計して、仕組みを作って、他部署に渡すという発想をしていたことに気づきました。
- ブログのワークフローをAIで効率化する → エンジニアの自分が設計した
- 議事録をAIで自動生成するツールを作る → エンジニアの自分が実装した
- ブログのアクセスランキングを可視化するツールを作る → エンジニアの自分が開発した
すべてエンジニアが作り、他の人に使ってもらうという構図です。
これはAI活用ではなく、AI設計です。
AI設計とAI活用は別物
ここで重要な区別があります。
| AI設計 | AI活用 | |
|---|---|---|
| やること | モデル選定、プロンプト設計、ワークフロー構築、ツール開発 | AIツールを使って自分の業務課題を解決する |
| 誰がやるか | エンジニア、データサイエンティスト | すべての職種 |
| 例 | Claude Codeのハーネス設計、アクセス分析ツール開発 | 広報がCanva AIでサムネイルを作る、HRがAIで採用文を作成する |
AI設計は確かにエンジニアの専門領域です。しかし、AI活用は違います。各領域の専門家が、自分の専門知識とAIを組み合わせて成果を出す行為です。
広報がサムネイルを作るとき、必要なのはブランディングの知識とファーストインプレッションの設計力です。AIはその実行手段に過ぎません。エンジニアが介在する必要はないのです。
この思い込みは私だけではなかった
日本リスキリングコンソーシアムのAI人材育成白書は、AI人材を次のように定義しています。
専門的な開発スキルを有するスペシャリストではなく、生成AIを活用し業務において具体的な成果を上げることができる人材
つまり、AI人材はAIエンジニアと同義ではありません。 しかし多くの組織で、この2つは混同されています。
BCGのAI Adoption Puzzleレポート（2025年）は、さらに厳しい現実を示しています。従業員の85%以上がAI活用の初期段階にとどまっている。そしてその原因は技術的な問題ではなく、組織的・心理的な壁だと結論づけています。
AIのことはエンジニアに聞こう、AIの導入はIT部門の仕事だ——この発想自体が、組織全体のAI活用を阻害しているのです。
そしてPreset社のブログでは、AI Enablement Engineerの役割をこう定義しています。
自分が10倍になるのではなく、50人を3倍にする
DevOpsがインフラをセルフサービスにしたように、AI Enablementとは知性のセルフサービス化です。エンジニアがAIを使って成果を出すことではなく、すべての人がAIを使える環境を作ることが本質です。
エンジニアファーストの落とし穴
エンジニアがAI推進を主導すると、無意識にこうなります。
- 自分が作って渡す → 他部署は使わされる側になる
- 技術的に正しい設計を優先する → 現場のニーズとずれる
- エンジニアの時間がボトルネックになる → 組織のAI活用速度が1人に依存する
サムネイルの例で言えば、私が最適なプロンプトを設計して広報に渡すよりも、広報が自分で試行錯誤してブランドに合うサムネイルを見つける方が、結果的に質も速度も高いはずです。なぜなら、ブランディングの専門家は広報だからです。
実際、私はアクセス分析ツールを1時間で作れましたが、キャッチーなタイトルやクリックされるサムネイルを作る技術は持っていません。データを分析して課題を特定するところまではエンジニアの強みですが、そこから先は別の専門性が必要です。自分の限界を認めることが、協働の出発点でした。
これはPlatform Engineeringと同じ構造
Platform Engineeringという考え方があります。その本質は「開発者が必要なものをセルフサービスで手に入れられる環境を作る」ことです。
振り返ると、セルフサービス化はずっと同じパターンで進んできています。
- インフラ: サーバー構築をエンジニアに依頼していた → クラウドで誰でもセルフサービスに
- 開発環境: 環境構築をインフラチームに依頼していた → Platform Engineeringでセルフサービスに
- AI活用: AIの仕組みをエンジニアに依頼している → 各専門家がセルフサービスで使えるべき
AI活用のセルフサービス化。これが、エンジニアファーストから脱却した先にある姿です。
各部署の専門家がAIを使える組織へ
私がたどり着いた協働モデルは、次のようなものです。
- エンジニア: 一次情報を書く（検証・実装・体験の記録）
- 非エンジニア（広報、マーケ等）: 自分の専門領域でAIを使って成果を出す（サムネイル設計、タイトル最適化、まとめ記事の企画）
- すり合わせるのは基準であって、作業ではない
エンジニアが非エンジニアにAIの使い方を教えるのではありません。それぞれの専門家が、自分の専門知識でAIを活用する。 各自が自分の領域でAIの恩恵を受ける構造です。
あなたの組織ではどうですか？
最後に、この記事を読んでいるAI推進担当の方に問いかけたいことがあります。
- AI活用の話が出たとき、最初に声がかかるのはエンジニアやIT部門だけになっていませんか？
- 各部署の専門家が、自分の業務にAIを使える環境は整っていますか？
- AIのことはよくわからないからと、現場が手を引いていませんか？
AI設計はエンジニアの仕事です。でも、AI活用はすべての人の仕事です。
そして、ブログのような情報発信も同じです。完璧な技術記事でなくていい。自分の業務でAIを試して得た小さな成功や失敗、そこから学んだことを共有するだけで価値があります。エンジニアも非エンジニアも、自分の専門領域で体験したことを言語化する場として、技術ブログはもっと気軽に使えるはずです。
エンジニアとして私ができることは、自分がAIを使って10倍の成果を出すことではなく、組織の50人がAIで3倍の成果を出せる環境を作ることだと、サムネイルの議論を通じて気づくことができました。
参考資料
- AI人材育成白書 — 日本リスキリングコンソーシアム
- AI Adoption Puzzle: Why Usage Is Up But Impact Is Not — BCG
- AI Enablement Engineer: The Highest-Leverage Role in Tech — Preset
- AI導入格差、鮮明に — 野村総合研究所
ACS 事業部のご紹介
私の所属する ACS 事業部では、開発者ポータル Backstage、Azure AI Service などを活用し、Platform Engineering ＋ AI の推進・内製化を支援しています。
www.ap-com.co.jp www.ap-com.co.jp www.ap-com.co.jp
また、GitHub パートナーとしてお客様に GitHub ソリューションの導入支援を行っています。 GitHub Copilot などのトレーニングなども行っておりますので、ご興味を持っていただけましたらぜひお声がけいただけますと幸いです。
一緒に働いていただける仲間も募集中です！ ご興味持っていただけましたらぜひお声がけください。
※求人名の冒頭に【ACSD】と入っている求人が当事業部の求人です
