AI業務活用支援の実績の見せ方｜出せない仕事をどう伝えるか

AI業務活用支援の実績の見せ方でつまずく理由は、実績がないことではありません。やった仕事のほとんどが、社名も業務内容も出せない形で終わっているからです。結論を先に書きます。出せない仕事は、固有名詞を落として構造だけを残せば伝わります。何の業種の、どういう性質の業務を、どういう順番で扱い、何を残したのか。この4つが書けていれば、社名がなくても発注側は判断できます。この記事では、公開できない案件しか手元にない状態から、依頼につながる実績の形を作る手順を整理します。公開許可の取り方、代わりになる材料の作り方、形式ごとの使い分け、やってはいけない見せ方まで扱います。

実績を出せない仕事が多い理由

AI業務活用支援は、他の受託業務より公開の壁が高い領域です。理由は2つあり、どちらも支援者の側では動かせません。

守秘の対象が業務そのものである

Webサイトの制作であれば、完成物が公開されているため、少なくとも「このサイトを作りました」とは言えます。AI業務活用支援は違います。対象になるのは社内の業務であり、成果物は社内の手順書、社内で使う仕組み、社内向けの研修資料です。外から見えるものが何も残りません。

さらに、どの業務にAIを入れたかという情報自体が、その会社の内部事情を示します。見積作成に時間がかかっていた、問い合わせ対応が人手で回っていた、報告書の作成が属人化していた。こうした事実は、外に出したくない種類の情報です。契約書に守秘の条項が入っていなくても、相手が嫌がる公開は関係を壊します。

相手の社内で誰が言い出したかの問題がある

もう一つの壁は社内政治です。外部の支援を入れた事実を、社内で大きく扱いたくない担当者は一定数います。自部門だけで解決できなかったと見られることを避けたい、経営に対して自分たちの成果として報告したい、といった事情があります。この場合、支援者の名前が外に出ること自体が担当者にとって不都合になります。

正直なところ、この事情を無視して掲載許可を強く求めると、その先の関係が悪くなります。相手が言いにくそうにしている時点で、公開はあきらめて別の見せ方に切り替えるほうが結果的に得です。

生成AI（ジェネレーティブAI）は、ユーザーの指示（プロンプト）をもとに文章や画像などを自動生成するAIです。例えば、企画書の草案を作成したり、広告画像を制作したりと、人手がかかる作業を効率化できます。 出典: www2.tisi.jp

やっていること自体は、外から見れば似た形に収まります。だからこそ、公開されている事例と自分の案件の違いを説明できないと、支援者としての差が伝わりません。固有名詞に頼らずに差を出す作業が、実績の見せ方の本体になります。

出せない前提で作る実績の書き方

公開できない案件を、そのまま実績として使える形に変換します。ここが最も手を動かす価値のある部分です。

固有名詞を落として構造だけを残す

社名、部署名、サービス名、扱った商材の名前。これらをすべて外しても、案件の骨格は残ります。残すのは、対象業務の種類、その業務が抱えていた詰まりの性質、こちらが取った手順、最後に相手の手元に残ったものです。

書き換えの例を挙げます。「アパレルブランドAのEC運営部門で、商品説明文の作成に生成AIを導入」という記述は、そのままでは出せません。これを「消費財を扱うEC事業者で、商品情報の原稿作成の標準化を支援。担当者ごとにばらついていた表現を整理し、下書きを生成して人が仕上げる手順に組み替えた。手順書と確認項目の一覧を納品」と書き換えます。社名は消えていますが、何ができる人なのかは前より明確に伝わります。

固有名詞を落とすと情報が減ると考えがちですが、実際は逆になることが多くあります。社名を書いた実績は「その会社の名前がすごい」で終わり、何をしたかが読まれません。構造だけを書くと、読み手は自社の業務に当てはめて読み始めます。

業種、規模、期間の3つで輪郭を作る

固有名詞を外すと、案件の大きさが伝わらなくなります。これを補うのが業種、組織の規模、関わった期間の3つです。「小売業」「情報システム部門を持たない規模」「およそ3か月」といった書き方であれば、相手を特定できず、輪郭は伝わります。

規模の表現は、従業員数より「情報システム部門があるかどうか」「担当者が専任か兼任か」のほうが、この領域では役に立ちます。専任の担当者がいる会社と、総務が兼任している会社では、支援の難易度がまったく違うからです。読み手が自社と近い条件を見つけられれば、その時点で問い合わせの動機になります。

数字が出せないときの代わりの表現

効果を数字で書けない案件は多くあります。相手が測っていない場合もあれば、測っていても公開できない場合もあります。数字が使えないときは、状態の変化で書きます。

「担当者以外でも一次案を作れる状態になった」「月末に持ち越されていた作業が当日中に終わる形に変わった」「新任者への引き継ぎが口頭説明から手順書に置き換わった」。この書き方であれば、守秘に触れずに変化が伝わります。数字を出せないことを言い訳にして「効率化に貢献」とだけ書くと、何も言っていないのと同じになります。状態の変化は、数字より具体的に書けることが多い材料です。

公開の許可を取る手順

出せる案件を1つでも持っていると、実績全体の説得力が変わります。許可は、取り方を工夫すれば通ることがあります。

契約の段階で先に確認しておく

最も通りやすいのは、契約を結ぶ時点で相談する方法です。案件が終わったあとに切り出すと、相手にとっては追加の判断であり、断るほうが楽になります。契約時であれば、条件の一つとして扱えます。

確認の文面は具体的にします。「業務内容を特定しない範囲で、業種と支援の種類のみを実績として記載してよいか」「社名の記載は不可、匿名での事例紹介は可」といった選択肢を並べ、どこまでなら差し支えないかを選んでもらいます。全面的に可否を問うと「原則不可」に倒れます。段階を用意すると、中間の答えが返ってきます。

終わったあとに依頼するときの伝え方

終了後に頼む場合は、相手に手間をかけない形で持ち込みます。掲載したい文面をこちらで作り、そのまま確認してもらう形が最も通ります。「掲載してよいですか」と聞くと、相手は何を書かれるか分からないまま判断することになり、慎重な答えになります。

文面を渡す際は、削除してほしい箇所に線を引いてもらう形にします。修正して返ってきたものが、そのまま掲載可能な文面になります。この方法だと、相手の作業は読むだけで済みます。5分で終わる依頼と、考える必要がある依頼では、返答率がまったく違います。

匿名の事例として提案する

社名を出せない相手でも、匿名なら通ることがあります。「業種と規模のみ記載し、社名と業務の詳細は伏せる」という条件を提示します。それも難しい場合は、支援した事実だけを伝える推薦の一文をもらえないかを聞きます。「必要な確認を丁寧に行ってくれた」といった内容であれば、社内の承認も取りやすい形です。

すべて断られることもあります。その場合は素直に引き下がります。断られた記録も自分の中では資産で、次の契約時に確認する項目が増えます。

実績の代わりになる材料を自分で作る

公開できる案件がない期間を、待って過ごす必要はありません。実績の代わりになる材料は自分で作れます。

手順書や確認項目の一覧を公開物として作る

案件で使った手順書を、特定の会社に依存しない形に書き直して公開します。「業務にAIを入れる前に確認する項目の一覧」「社内で使う際の判断の分かれ目」といった内容です。これは守秘に触れません。手順の型は支援者自身の資産であり、相手の情報ではないからです。

公開した手順書は、実績そのものより強く働くことがあります。発注する側は、支援者が何をどの順番で考えるかを知りたがっています。実績の一覧は結果しか示しませんが、手順書は考え方を示します。相談の入口として機能する材料です。

自分の業務で試した記録を残す

自分の受託業務や個人の作業にAIを組み込み、その過程を記録します。何を試して、どこでうまくいかず、どう変えたか。この記録は他人の情報を含まないため、制約なく公開できます。

失敗した記録のほうが読まれます。うまくいった話は他にも大量にありますが、うまくいかなかった条件を具体的に書いた記録は少ないためです。「この種類の業務には向かなかった」という記述は、発注側にとって判断材料になります。読んだ相手が「では自社のこの業務はどうか」と考え始めれば、相談につながります。

小さくても公開できる事例を1つ作る

知人の事業者、地域の小規模な団体、非営利の活動など、公開の許可を得やすい相手と1件だけ取り組む方法があります。規模が小さくても、公開できる事例が1つあるだけで、説明の起点ができます。

この1件は、実績の一覧を埋めるためではなく、話の材料として使います。面談で「たとえば」と具体的な話ができる状態と、抽象的な説明しかできない状態では、伝わり方が変わります。取り組む相手を選ぶ際は、業務の性質が自分の狙う領域と近いことを条件にします。

書き始める前に手元の案件を棚卸しする

いきなり実績の文面を書こうとすると、書けない案件ばかりが目について手が止まります。先に棚卸しをして、案件を種類に分けてから書くほうが速く進みます。

案件を公開の可否で3つに分ける

手元の案件を、社名まで出せるもの、業種と内容までなら出せるもの、まったく出せないものの3つに分けます。この分類をしていない状態では、どの案件をどう書くか毎回考えることになり、作業が重くなります。

分類の判断は、契約書の守秘の条項と、相手との関係の両方を見ます。条項に明示がなくても、相手が嫌がると分かっている場合は出せない側に入れます。逆に、条項があっても業種のみの記載なら問題にならない場合が多く、迷う案件は相手に確認します。確認して断られた案件は、次からは考えずに出せない側として扱えます。

まったく出せない案件も、書き方を変えれば材料になります。複数の案件をまとめて「同種の業務を複数の事業者で扱った」という形にすれば、個別の案件を特定できません。単独では出せないものが、束ねると出せるようになるという点は覚えておく価値があります。

案件ごとに判断の理由を書き出す

分類が終わったら、案件ごとに「なぜその手順にしたか」を1行ずつ書き出します。対象業務をその範囲に絞った理由、最初に確認した項目を選んだ理由、途中で方針を変えた理由。この材料が、後で文面を作るときの中身になります。

作業内容だけを並べた記録は、どの案件も似た形になります。判断の理由は案件ごとに違うため、ここが差になります。棚卸しの段階で理由を書き出しておくと、応募先に合わせて文面を組み替えるときに、毎回思い出す手間がなくなります。

残っている成果物を集める

手順書、確認項目の一覧、研修の資料、設計のメモ。案件ごとに何を作ったかを一覧にします。中身は出せなくても、どういう種類の成果物を作れる人なのかは伝えられます。「手順書と確認項目の一覧を納品」という記述があるだけで、相手は納品物の形を想像できます。

成果物の一覧は、次の提案の材料にもなります。似た案件で「前回はこの形で納めた」と言えると、相手は完成形を先に把握できます。何が納品されるか分からない状態は、発注側にとって最も判断しにくい状態です。

発注側が実績のどこを見ているか

書く側と読む側では、注目する箇所が違います。読む側の見方を知っておくと、力を入れる場所が変わります。

自社と条件が近いかどうか

発注側が最初に探すのは、自社に近い条件の案件です。業種が同じであること以上に、組織の規模と体制が近いことが重視されます。情報システム部門を持たない会社の担当者は、大企業の事例を読んでも自社に当てはめられません。

このため、実績には規模と体制の情報を必ず入れます。「専任の担当者がいない体制で」「情報システム部門を持たない規模で」といった記述は、相手を特定しないまま条件を伝えられます。近い条件を見つけた読み手は、その1件を最後まで読みます。

うまくいかなかった場面の扱い方

発注側は、順調に進んだ話より、予定どおりにいかなかったときの動きを知りたがっています。支援の途中で前提が崩れることは珍しくないためです。うまくいかなかった場面と、そこでどう判断したかが書かれている実績は、そこだけが読まれることもあります。

失敗を書くと不利になると考えて省く例は多いのですが、実際は逆に働きます。すべて成功した実績しか並んでいない場合、読み手は「都合の悪い案件を隠している」と受け取ります。方針を変えた理由まで書いてあるほうが、判断できる相手だと伝わります。

誰と組んで、どこまでを自分がやったか

チームで動いた案件では、自分の担当範囲が明記されているかどうかが見られます。範囲が曖昧な記述は、面談で詳細を聞かれた際に答えられず、その時点で信用が下がります。

書き方としては、案件全体の概要を1行で書き、そのうち自分が担当した部分を明示します。担当範囲が狭くても、その範囲で何を判断したかが書ければ問題になりません。範囲の狭さより、書いてあることと実際が一致していることのほうが重視されます。

見せ方の形式ごとの使い分け

同じ内容でも、置く場所によって書き方を変えます。形式を間違えると、内容が良くても読まれません。

一覧の形で並べる場合

提案資料やプロフィールに載せる一覧は、1件あたり3行程度に収めます。業種と規模、支援の内容、残したもの。この順で並べると、読み手は自社に近い行を探せます。

一覧の並び順は、時系列ではなく関連度にします。応募先や提案先の業種に近いものを上に置きます。時系列で並べると、最も伝えたい案件が下のほうに埋もれます。件数を増やすことより、上位の数件が相手に刺さるかどうかが結果を左右します。

自分の支援がどの職種の範囲に近いかを言葉にしておくと、一覧の書き分けも楽になります。開発や外部サービスとの接続を含む案件であればソフトウェア作成者の年収・単価相場が扱う領域に近く、手順書や研修資料の整備が中心であれば著述家，記者，編集者の年収・単価相場の領域に近くなります。どちらに寄っているかで、相手が期待する成果物も変わります。

事例を1本だけ深く書く場合

自分のサイトや提案書に載せる詳細な事例は、1本を深く書きます。背景、最初に確認したこと、途中で変えた判断、最後に残したもの、振り返って改善すべきだった点。この順で構成すると、読み手は支援の進み方を追体験できます。

深く書く事例には、うまくいかなかった部分を必ず入れます。全部うまくいった事例は宣伝として読まれ、信用されません。途中で方針を変えた箇所とその理由を書くと、判断の根拠が見えます。発注側が知りたいのは成功の話ではなく、予定どおりに進まなかったときにこの人がどう動くかです。

面談で口頭で話す場合

面談では、実績の一覧を読み上げてはいけません。相手の業務を先に聞き、それに近い案件を1つだけ選んで話します。話す順番は、相手が抱えていた状況、こちらが最初に確認したこと、実際に取った手順です。

守秘に触れる質問が来た場合の答え方も、先に決めておきます。「その部分はお答えできませんが、同じ性質の業務でどう進めたかはお話しできます」と返せば、相手は不快になりません。逆に、聞かれるままに詳細を話す支援者は、自社の情報も同じように扱われると受け取られます。答えられない場面をきちんと作ることが、そのまま信頼の材料になります。

実績の見せ方で失敗する型

同じ材料を持っていても、書き方で結果が変わります。避けるべき型を3つ挙げます。

表現を盛って後で崩れる

「大幅に効率化」「劇的に改善」といった強い言葉は、根拠を聞かれた瞬間に崩れます。数字を出せない案件でこの表現を使うと、確認のしようがない主張だけが残ります。控えめに書いて実際が上回るほうが、契約後の関係が安定します。

役割を大きく書くのも同じ危険があります。チームの一部として関わった案件を、全体を主導したかのように書くと、面談で詳細を聞かれたときに答えられません。関わった範囲を正確に書き、その範囲で何を判断したかを厚く書くほうが伝わります。

抽象的すぎて何ができるか伝わらない

守秘に配慮するあまり、「業務改善の支援」「AI活用のコンサルティング」といった書き方だけになる例は多く見られます。この表現からは、何ができる人なのかが読み取れません。守秘に触れるのは固有名詞と数字であり、業務の種類と手順は書けます。

書けるかどうか迷ったら、その記述から相手の会社を特定できるかを基準にします。特定できないなら書いて構いません。業種を大きめの括りにする、期間をぼかす、複数の案件を合わせて傾向として書く。この3つの手当てで、ほとんどの記述は出せる形になります。

他人の成果を自分の実績として書く

チームで動いた案件や、他社が主導した案件を自分の実績として書くと、後で必ず問題になります。この領域は関係者が狭く、話が伝わります。共同で行った案件は、共同であることを明記したうえで自分の担当を書きます。

同様に、事例の記述に相手の社内資料の表現をそのまま使うことも避けます。相手が作った表現は相手のものです。内容を自分の言葉に置き換えたうえで、構造だけを使います。

実績を書き足し続ける仕組みを作る

実績の見せ方は、一度整えて終わりにはなりません。案件が増えるたびに書き足す必要があり、この作業が滞ると、数年前の内容のまま止まります。

案件の終了時にその場で書く

書き足す作業は、案件が終わった直後に済ませます。経緯を覚えているうちであれば、判断の理由も含めて30分程度で書けます。数か月おいてからまとめて書こうとすると、何をしたかしか思い出せず、作業の羅列になります。

終了時の作業として、納品物の確認と一緒に組み込むと忘れません。請求書を出すタイミングで実績の記述も1件足す、という形にしておけば、習慣として続きます。書いた記述は公開用と手元用の2つを作り、手元用には社名と詳細も残しておきます。後で許可が取れた場合に、そのまま公開用へ変換できます。

応募先に合わせて並べ替える

書きためた記述は、そのまま全部を出すのではなく、応募先や提案先に合わせて上位の数件を選び直します。関連する案件を上に置き、関連の薄いものは省くか下に回します。件数が多いことは強みになりません。読み手が最初の数件で自社に近いものを見つけられるかどうかが分かれ目です。

省いた案件は消さずに残しておきます。別の提案では上位に来ることがあるためです。選び直す作業自体は、一覧が整理されていれば数分で終わります。

古くなった記述を書き直す

AI業務活用支援の領域は、使う道具も社内の受け止め方も変わり続けています。数年前の案件をそのままの表現で載せていると、内容が古く見えます。道具の名前に依存した記述は、業務の性質を中心にした記述へ書き直します。

書き直すとき、当時の判断を今の基準で書き換えないよう注意します。当時の条件で最善だった判断は、そのまま書いて構いません。条件が違えば判断も変わるという事実は、読み手にも伝わります。無理に今風の表現に直すと、事実と合わない記述になります。

市場を長く見てきた立場からの観察

20年この市場を見てきた立場から言えば、依頼につながる実績の書き方には共通点があります。書いてある案件の数ではなく、1件あたりの記述に判断の跡が残っているかどうかです。何をしたかだけを並べた一覧は読み飛ばされ、なぜその順番にしたかが1行入っている記述は最後まで読まれます。発注する側は作業者ではなく判断できる相手を探しているため、判断の跡が信用の材料になります。

運営者として見てきた限りでは、公開できる実績が少ない人ほど、面談での説明が丁寧になる傾向があります。書けないぶんを口頭で補う習慣がつくためで、結果として相手の理解が深まり、条件の詰めも早く進みます。中間に人が入らない直接取引の形では、この説明がそのまま相手に届きます。手数料0%で当事者同士がやり取りする在宅ワーク仲介サイトの仕組みでは、依頼する側が同じ予算でより多くを頼め、受け手の手取りも厚くなります。伝言が挟まると、判断の跡の部分が最初に落ちます。

実績を次の依頼につなげる

実績の見せ方を整えると、問い合わせの内容が変わります。何ができるかを聞かれる段階から、この業務は扱えるかを聞かれる段階に移ります。後者の問い合わせは、条件が具体的で、決まるまでが速い形です。

作業としては、案件が終わるたびに書き換え済みの記述を1件ずつ足していくだけです。終了直後は経緯を覚えているため、書くのに時間がかかりません。数か月後にまとめて書こうとすると、判断の理由が思い出せず、作業の羅列になります。支援の範囲がどこまでを指すかを確認したい場合はAIコンサル・業務活用支援のお仕事が扱う業務の分け方が参考になり、隣接する領域まで広げるならAI・マーケティング・セキュリティのお仕事やアプリケーション開発のお仕事で扱われる仕事の内容が、書き分けの目安になります。

書類の書式そのものを整える力も、実績の伝わり方に影響します。読みやすい書式で出された実績は、相手の社内でそのまま回覧されます。この素養はビジネス文書検定が扱う範囲と重なります。技術的な統制の話が絡む案件では、情報システム部門と会話が成立するかどうかも判断材料になり、CCNA（シスコ技術者認定）の学習範囲は共通語として役立つ場面があります。海外の依頼者に実績を示す場合の作法はUpworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法にまとまっており、長い職務経験を実績として組み直す進め方は定年後のフリーランス独立｜退職金を活かした起業プランと注意点が具体的です。

よくある質問

Q. 守秘義務があると、実績は一切書けないのですか？

書けます。守秘の対象になるのは社名や業務の詳細であり、業務の種類、支援の手順、残した成果物の性質は書けることが多くあります。その記述から相手の会社を特定できるかどうかが判断の基準です。業種を大きめの括りにする、期間をぼかす、複数案件を傾向としてまとめる。この3つの手当てで、ほとんどの記述は出せる形になります。

Q. 公開許可はいつ頼むのが通りやすいですか？

契約を結ぶ時点です。終了後に頼むと相手にとって追加の判断になり、断るほうが楽になります。契約時なら条件の一つとして扱えます。頼むときは可否を問うのではなく、社名は伏せて業種のみ記載、匿名での事例紹介は可、といった段階を並べて選んでもらうと中間の答えが返ってきます。

Q. 実績がまだ1件もない場合は何を見せればよいですか？

自分で作れる材料を使います。案件に依存しない形に書き直した手順書や確認項目の一覧、自分の業務にAIを組み込んだ記録、公開の許可を得やすい相手との小さな取り組み。この3つは他人の情報を含まないため制約なく出せます。特に、うまくいかなかった条件を具体的に書いた記録は読まれ、相談の入口として働きます。

Q. 効果を数字で書けないときはどう表現しますか？

状態の変化で書きます。担当者以外でも一次案を作れるようになった、月末に持ち越されていた作業が当日中に終わる形に変わった、引き継ぎが口頭説明から手順書に置き換わった、といった形です。数字が出せないことを理由に「効率化に貢献」とだけ書くと何も伝わりません。状態の変化のほうが具体的に書ける場面は多くあります。

Q. 面談で実績を話すとき、どこまで答えてよいか迷います？

答えられない範囲をあらかじめ決めておき、その場で明示します。お答えできない部分がある旨を伝えたうえで、同じ性質の業務でどう進めたかに話を移せば会話は続きます。聞かれるままに他社の詳細を話す相手は、自社の情報も同じように扱われると受け取られます。答えない場面を作ること自体が信頼の材料になります。