AI開発 （2026年10月4日 更新） 6 min read

AI活用を開発チームの外へ広げるとき、ツールより先に「使いどころ」を設計する

非エンジニア部門へAI活用を広げようとして、ツールを使える状態にするだけでは定着しなかった。詰まった理由を整理し、業務ごとにAIが効く作業と効かない作業を分けて使いどころから設計し直している途中の記録。

AI開発組織設計チーム開発

開発チームで使っている生成AI（Claude）を、非エンジニアの部門にも広げようとしている。結論から書くと、ツールを使える状態にして案内するだけでは広がらなかった。いまは順番を入れ替えて、業務ごとの「使いどころ」を先に設計するところからやり直している。

成功事例ではなく、途中経過の記録だ。詰まった理由の整理と、使いどころを書き出すときの考え方をまとめておく。

背景：開発チームの外に届いていない

日常的にAIを業務で使っているのは、開発チームと、その外のごく一部に限られている。ほかの部門にはほとんど届いていない。

ツールを用意して「使えますよ」と伝えることはできる。自分は最初、便利なツールがあれば自然に使われ始めると考えていた。実際にはそれだけでは動かなかった。

開発チーム内での導入の経緯と利用指針（入力してはいけない情報など）はClaude Codeを実務導入して開発フローが変わった話に書いたので、ここでは扱わない。この記事は、開発チームの外へ広げる段階の話だ。

詰まった理由

理由を整理すると、3つに分けられた。

1. 何から始めればいいかが分からない

これが一番大きい。AIが便利らしいことは何となく知られている。ただ「自分の業務のどこに、どう使えばいいのか」が見えていない。

「AIを使ってください」という案内は、「英語を話してください」と同じくらい漠然としている。入口が分からないものは使われない。

2. 組織としてのゴールが言葉になっていない

個人の作業でAIを使うことと、組織としてどの業務にどう使うかを決めることは別の話だ。後者がまだ言葉になっていない。これは広げようとしている自分の側の宿題でもある。

一般に、ゴールがないまま道具だけが先に手に入ると、出力を作ること自体が目的になりやすい。作れるものが増えても、それが業務のどこを楽にしたのかを説明できない状態になる。

3. 方針と優先順位が決まっていない

全社で使うには、予算・方針・優先順位が要る。どの業務から着手するかが決まっていない段階では、現場で個別に勧めても部分的な利用で止まる。これも、使いどころを具体的に示せていないことの裏返しだと考えている。

共通していること

3つに共通しているのは、「何のために、どこで使うのか」が設計されていないことだ。

入口が分からなければ使われない。目的がないまま使えば、出力が増えるだけになる。どちらも、使いどころの設計がないことから出てくる。

やり直し：使いどころを先に設計する

そこで、ツールを配ることより先に、使いどころを設計することにした。非エンジニアの業務の中で「この作業はAIでこう楽になる」という具体的なユースケースを、ひとつずつ言葉にしていく。

候補として挙げているのは次のような作業だ。

  • 議事録
  • 報告書の下書き
  • データの整理
  • メールの叩き台

議事録でのAI利用についてはAIノートテイカーで議事録が変わったに書いている。

効く作業と効かない作業を分ける

使いどころを書き出すときは、作業を2種類に分けて考えている。自分が開発業務で使い続けてきた中での整理であり、まだ確定したものではない。

区分作業の例理由
AIが効く下書き・叩き台の作成、断片的な情報の整理、文章の構成背景情報を渡せば叩き台が速く出る。断片的な知識を一本の流れに並べ直すのが得意
AIに任せない事実の確認、最終的な判断もっともらしい誤りが自信のある文体で出てくる。前提から外れると的外れな回答になる

右側の「理由」は、自分が実際に踏んだ落とし穴から来ている。誤った情報がそれらしく出てきたこと、渡した文脈から外れた質問をして的外れな回答を受け取ったこと、判断を委ねすぎて後悔したこと。便利さを伝えるだけでなく、この限界を一緒に伝えないと、使いどころの線が引けない。

もうひとつ前提にしているのは、AIの出力は使う側の理解の解像度を超えない、ということだ。業務を分かっている人が背景を渡して初めて、使える叩き台になる。だからユースケースは、その業務を担当している人の言葉で書く必要がある。

ユースケースの書き方

「AIを使おう」ではなく「あなたのこの作業が、これで減る」と示すために、ユースケースは次の項目で書き出そうとしている。

作業名　　　　：（例）会議後の報告書の下書き
いまの手順　　：誰が、何を見て、どのくらいの手間で作っているか
AIに頼む部分　：下書き・整理など「効く作業」に当たるところ
渡す背景情報　：目的、読み手、元になるメモ
人が確認する点：事実関係、数字、最終的な判断
入力しない情報：利用指針で禁止しているもの

「人が確認する点」と「入力しない情報」を必ず書く欄にしているのは、効く作業と任せない作業の線を、ユースケースごとに明示するためだ。

教え方

教えるときの方針は、いまのところ次の3点だ。

  • 機能の説明からではなく、相手の具体的な作業ひとつから始める
  • うまくいく例と一緒に、誤りが出る例・的外れになる例も見せる
  • 出力をそのまま使わず、どこを自分で確認するかまでを一連の手順として伝える

うまくいっていない点

この設計はまだ途中だ。ユースケースを整理している最中で、他部門への展開が進んだとは言えない。上の表やテンプレートも、非エンジニアの業務で検証できたものではない。

ゴールの言語化も残っている。個別のユースケースを積み上げた先で、組織としてどこまでをAIに任せるのかを言葉にする必要があるが、そこまでは届いていない。

まとめ

  • ツールを使える状態にして案内するだけでは、開発チームの外には広がらなかった
  • 詰まった理由は「入口が分からない」「ゴールが言葉になっていない」「方針と優先順位が決まっていない」の3つで、共通点は使いどころが設計されていないこと
  • 順番を「ツールを配る → 使いどころを設計する」に入れ替えた。作業単位で、AIに頼む部分と人が確認する部分を分けて書き出している
  • 便利さと一緒に限界（誤り、的外れな回答、判断の委ねすぎ）を伝える
  • 展開は現在進行形で、検証はこれから

広がらずに止まったことで、広がらない理由を考えることになった。順番を間違えていたと分かったのは、その結果だ。

関連記事:

関連記事

↑