機械学習開発の実績の見せ方｜出せない仕事をどう伝えるか

2026年5月2日

丸山桃子

この記事のポイント

✓機械学習開発の実績の見せ方を
✓守秘義務で中身を出せない前提から整理します
✓課題設定・データ・手法・運用の4層に分けて書き換える手順

機械学習開発の仕事を続けていると、「一番よくできた案件ほど外に出せない」という状態になります。学習データは顧客の資産で、モデルは競争力そのもの、精度の数字は社外秘。結果として、手元に残るのは口では言えるのに書けない実績ばかりになります。この記事では、機械学習開発の実績の見せ方を、出せない情報を無理に出さないまま説得力だけを引き上げる手順として整理します。扱うのは、実績を4つの層に分解して書き換える方法、数字を伏せたまま成果を伝える表現、そして経歴書と面談と公開用ポートフォリオで書き分ける基準です。

機械学習開発の実績が外に出せなくなる構造

機械学習の受託開発は、ほかの開発領域と比べて成果物の秘匿性が高くなりやすい分野です。理由は一つではなく、契約・データ・事業の三方向から同時に縛りがかかります。ここを整理しておかないと、「守秘義務があるので何も言えません」という一言で面談が終わってしまいます。

契約上の制約：NDAが縛るのは範囲であって存在ではない

多くの受託契約には秘密保持条項が含まれ、業務で知り得た情報の開示が禁止されます。ここで誤解が起きやすいのは、NDAが禁じているのは「開示された情報の内容」であって、「そのプロジェクトに関与した事実」まで一律に禁じているわけではないという点です。契約書には、顧客名の公表可否、業務内容の抽象的な言及の可否、公表前の事前承諾の要否が個別に書かれています。

実務では、契約締結時に次の三点を確認しておくと後の実績づくりが楽になります。第一に、顧客名を挙げてよいか。第二に、業種と規模を伏せた形での言及が可能か。第三に、公表したい場合の承諾手続きはどこに申請するか。これらは契約時なら数分で確認できますが、案件終了後に問い合わせると担当者が異動していて答えが返ってこないことがあります。実績の見せ方は、案件が終わってからではなく、契約書に署名する前から始まっています。

データの制約：学習データそのものが機密

機械学習の開発では、コードよりも学習データのほうが機密性が高いことがよくあります。医療画像、購買履歴、通話ログ、製造ラインの検査画像。いずれも個人情報や営業秘密を含み、加工後のデータであってもサンプルの持ち出しは認められないのが通常です。

このため、Webアプリケーション開発なら「画面のスクリーンショットを1枚出す」で済むところが、機械学習開発では代替手段を用意しないと成立しません。データの中身を出さずに、データの性質だけを語る訓練が必要になります。具体的には、件数の桁、ラベルの偏り、欠損の傾向、時系列かどうか、といった構造の話に置き換えます。これなら顧客固有の情報を漏らさずに、扱った難易度を伝えられます。

事業上の制約：精度の数字が競争力を示してしまう

三つ目の制約は、精度指標そのものが顧客の競争力を示すという点です。不正検知の検出率や、需要予測の誤差率は、公開された瞬間に競合へのヒントになります。顧客が数字の公開を渋るのは、後ろ暗い理由があるからではなく、正当な事業判断です。

だからこそ、発注する側も「数字を出せない相手」であることを前提に候補者を見ています。数字が出てこないこと自体は不利になりません。不利になるのは、数字が出せないことを理由に説明そのものを放棄した場合です。

実績を4つの層に分解して書き換える

出せない実績を書けるようにする作業は、要するに抽象度の調整です。案件の記憶を、そのままの粒度で書こうとするから書けなくなります。次の4層に分解すると、どの部分が機密でどの部分が自分の技能かがはっきりします。

第1層：課題設定をどう定義したか

最初の層は、そのプロジェクトが何を解こうとしていたかです。ここは顧客固有の情報を含みやすい一方で、抽象化しやすい層でもあります。「特定小売チェーンの店舗別発注量の最適化」は機密でも、「日次の需要予測を業務オペレーションに載せる案件」なら業界の一般的な課題として書けます。

この層で書くべきなのは、与えられた要望をどう技術課題に翻訳したかという判断です。発注側は「AIで何とかしてほしい」という粒度で相談してくることが多く、それを回帰問題として解くのか、分類問題として解くのか、そもそも機械学習を使わずルールベースで足りるのかを決めるところに専門性が出ます。この判断過程は顧客の秘密ではなく、判断した側の技能です。

第2層：データをどう扱ったか

第2層はデータの前処理と設計です。ここは中身を出せない代わりに、扱いの難しさを構造で語ります。ラベルが不均衡だったのでどう対処したか、欠損の多い列をどう扱ったか、時系列の漏れ（未来の情報が特徴量に混入する状態）をどう防いだか。これらは機械学習の実務で最も時間を使う部分でありながら、経歴書では抜け落ちやすい部分です。

とくにデータリークの防止は、経験者と未経験者の差が出る項目です。検証データの分割を時系列で切ったか、同一ユーザーが訓練と検証にまたがらないようにグループ分割を使ったか。こうした話ができるかどうかで、実運用に耐えるモデルを作った経験の有無が透けて見えます。

第3層：手法の選択と比較の過程

第3層は使った手法です。ここは公開情報の塊なので、比較的自由に書けます。ただし「PyTorchを使いました」だけでは技能を示せません。書くべきなのは選択の理由と、選ばなかった案です。

勾配ブースティングで足りる問題に深層学習を持ち込まなかった、推論を端末側で動かす制約があったので軽量なモデルに寄せた、説明性が要件だったので線形モデルと決定木を優先した。こうした取捨選択は、要件を理解した上での判断であり、発注側が最も知りたい部分です。

第4層：運用にどう載せたか

第4層は運用です。モデルを作って終わりの案件と、業務に載せて回し続けた案件では、経験の重みがまったく違います。推論の実行基盤をどう用意したか、再学習の頻度をどう決めたか、精度低下を誰がどう検知する設計にしたか。

とくに重要なのは、デプロイ後のモニタリングと再学習のフェーズです。市場やユーザー行動の変化に伴い、モデルが学習したデータと実際の運用データの間にずれが生じるため、定期的な精度検証と再学習が不可欠です。出典: annotation.brycen.co.jp

運用まで見た経験があるなら、それは実績の中で最も強い部分になります。しかも運用の設計は顧客固有の秘密を含みにくく、書きやすい層でもあります。実績が出せないと悩んでいる人ほど、この第4層を書き忘れています。

数字を出せないときに成果をどう伝えるか

精度や効果の絶対値を出せない場合でも、成果の伝え方には複数の段階があります。上から順に、出せる範囲で最も情報量の多いものを選びます。

相対値に置き換える

絶対値が機密でも、改善の相対値なら開示できることがあります。「既存のルールベース処理と比べて誤検知を減らした」「従来モデルより推論時間を短縮した」といった表現です。比率まで出せるなら出し、出せないなら方向だけを示します。この形式は、顧客の事業規模や絶対的な精度水準を推測させないため、承諾を得やすい傾向があります。

業務指標に置き換える

技術指標が出せないときは、業務がどう変わったかで語る手があります。目視確認していた工程が抽出結果の確認だけになった、担当者の作業が日次から週次になった、というような変化です。これは顧客の内部数値を出さずに価値を説明できるうえ、発注側にとっては技術指標より理解しやすい表現になります。

公開されている事例を見ると、成果の語り方の型が分かります。

【参考事例】名古屋グランパス、テクムズ：テクムズの開発した顔認証システム「顔パス」を利用して名古屋グランパスは入場者を把握する実証実験を行った。来場者の性別や年齢などの属性も取得しマーケティングに活かす予定。他にもデジタルサイネージの広告の効果検証も実施。ディスプレーの正面に2.5秒以上顔を向けた場合を広告を見た来場者と定義。実際に広告を見たのは133人、そのうち24人が来店し、その割合は18%。広告による来場効果を検証することができた。出典: sorabatake.jp

この記述で情報量を担っているのは18%という数字だけではありません。「2.5秒以上顔を向けた場合を広告を見たと定義した」という定義の部分が、技術者の仕事を示しています。数字を出せない案件でも、この定義づくりの話は書けます。何をもって成功とみなすかを決めた過程は、多くの場合、機密ではなく手法だからです。

検証の設計で語る

三つ目は、評価をどう設計したかで語る方法です。オフライン評価だけで終わらせずA/Bテストまで持っていったか、ビジネス指標と技術指標の対応をどう定義したか、閾値をどう決めたか。閾値の決め方は、見逃しと誤警報のどちらのコストが高いかという業務理解が必要な部分で、そこを説明できる人は多くありません。数字を1つも出さずに、実務経験の深さだけを伝えられる領域です。

提出先ごとに書き分ける

同じ実績でも、渡す相手と場面によって適切な粒度が変わります。ここを一律にすると、経歴書が抽象的すぎて読み飛ばされるか、公開ポートフォリオが具体的すぎて契約違反になるかのどちらかになります。

職務経歴書に書く場合

経歴書は特定の相手に渡す非公開文書なので、公開ポートフォリオより踏み込めます。顧客名は伏せ、「製造業向け」「小売業向け」のような業種表記に置き換えるのが一般的です。1案件あたりの記載は、課題・担当範囲・使用技術・工夫した点・結果の5項目に固定すると読み手が比較しやすくなります。

担当範囲の書き方には注意が必要です。チームで開発した案件を、あたかも単独で完遂したように書くと、面談での深掘りで矛盾が出ます。「データ前処理と特徴量設計を担当」「推論APIの実装と監視設計を担当」のように、自分が手を動かした範囲を明示するほうが、結果的に信頼を得られます。

面談で口頭説明する場合

面談は文書より柔軟です。相手も同じ業界の技術者であれば、どこまでが言える範囲かを互いに理解しています。「詳細は守秘義務でお話しできませんが、構造としては同種の課題です」と前置きしたうえで、手法と判断の話に進むのが標準的な進め方です。

ここで効くのが、案件を1つも特定しない形の技術説明です。「不均衡データの二値分類で、見逃しコストが高い業務」という抽象化まで持っていけば、どの案件の話かは分からないまま、扱った問題の難易度は正確に伝わります。この抽象化の訓練は、実際に声に出して練習しておく価値があります。文章で書けても、口頭では固有名詞が滑り出てしまうことがあるためです。

公開ポートフォリオに載せる場合

公開する場合は、受託案件をそのまま載せる発想を捨てるのが安全です。代わりに、公開データセットを使った再現実装、コンペティションの取り組み、業務で使った手法を一般化した技術記事、といった自作物で構成します。公開できる素材で技能を示し、受託案件の実績は非公開文書と面談に回す。この二階建てにすると、契約を守りながら露出も確保できます。

ポートフォリオの構成については、企業側が何を見ているかを踏まえた整理が参考になります。

これらを踏まえることで、企業が求める人材像や希望する技術と、ポートフォリオをマッチングできます。ただし、ポートフォリオは自分のスキルや経験を掲載するものです。必ずしも志望企業によせすぎる必要はなく、自分の趣味で作った制作物なども掲載してよいです。出典: career.levtech.jp

案件を扱う分野の広がりを知りたい場合は、業務活用の相談から入る仕事の輪郭をまとめたAIコンサル・業務活用支援のお仕事が参考になります。モデル開発だけでなく、要件定義や社内活用の設計まで含む案件がどう組み立てられているかが分かります。

発注側が実績から読み取ろうとしていること

実績の見せ方を考えるときは、読む側の目的から逆算すると精度が上がります。発注側が実績欄を読む理由は、過去の華やかさを確認するためではありません。次の3点を判定するためです。

判定1：任せた場合に手戻りが出ないか

最も重視されるのは、途中で止まらないかどうかです。前処理の段階でデータの品質問題が出たときに自力で解けるか、精度が要件に届かないときに代替案を出せるか。ここを見るために、発注側は失敗や制約への対処が書かれているかを探しています。

順調だった話ばかりの経歴書は、この観点では情報量がありません。「初期のモデルが要件精度に届かず、特徴量を業務ヒアリングから作り直して達成した」といった記述のほうが、はるかに強い材料になります。困難とその解決を1案件につき1つ書いておくと、面談での話も広がります。

判定2：業務側と話が通じるか

機械学習の受託では、発注側が技術に詳しくないケースが珍しくありません。そのため、技術者が業務担当者と直接話して要件を固める場面が多く発生します。実績欄に「業務部門へのヒアリングを担当」「評価指標を業務側と合意して定義」といった記述があると、この能力があると読み取ってもらえます。

判定3：作った後まで面倒を見られるか

三つ目は運用です。前述の第4層がここに効きます。作って納品して終わりの経験しかない人と、運用開始後の精度低下に対応した経験がある人では、任せられる案件の幅が変わります。監視の仕組み、再学習の判断基準、障害時の切り戻し方針。これらに触れた実績は、継続的な依頼につながりやすくなります。

関連する職域の広がりを見ておくと、自分の実績をどの文脈に置くと伝わるかが判断しやすくなります。データ活用とセキュリティ、マーケティング領域が交差する案件の傾向はAI・マーケティング・セキュリティのお仕事に整理されています。推論結果を組み込む先のシステム側まで担当する場合はアプリケーション開発のお仕事の内容も合わせて確認しておくと、担当範囲の説明がしやすくなります。

実績の見せ方でつまずきやすい点

つまずき1：抽象化しすぎて何も言っていない

守秘義務を意識しすぎると、「大手企業向けにAIシステムを開発しました」のような、情報がゼロの記述になります。この書き方は、経験の有無を判別できないため読み飛ばされます。抽象化するのは顧客の識別情報だけで、技術の中身は具体的に書くのが原則です。業種は伏せても、扱ったデータの構造と手法の選択理由は残します。

つまずき2：使用技術の羅列で終わる

ライブラリ名やクラウドサービス名だけを並べた記述もよく見ます。名前を挙げるだけでは、触ったことがあるのか設計まで担ったのかが区別できません。技術名には必ず、それを何のためにどう使ったかを1文添えます。

つまずき3：精度の数字を出せる場面で出していない

逆のパターンもあります。公開データセットでの再現実装や、コンペの成績、社内向けの検証など、出せる数字があるのに機密扱いにして伏せているケースです。出せるものと出せないものを一度仕分けし、出せるものは具体的に書きます。仕分けの基準は、顧客の事業情報が推測できるかどうかの一点です。

つまずき4：更新が止まっている

実績は、案件が終わった直後に書くのが最も正確です。数か月経つと、なぜその手法を選んだかという判断の理由が記憶から抜けます。案件終了時に、公開可否とは無関係に、手元の記録として判断の履歴を残しておくことをすすめます。後から抽象度を下げることはできませんが、上げることはいつでもできます。

実績を棚卸しして清書するまでの手順

書き方の方針が決まったら、実際の作業に落とします。頭の中だけで整理しようとすると、印象に残った案件だけが残って全体像が偏ります。次の順番で紙の上に出すのが確実です。

手順1：案件を時系列で全部並べる

まず、公開可否を一切考えずに、関わった案件を時系列ですべて並べます。ここで判断を挟むと手が止まるので、思い出す作業と選別する作業を分けるのが要点です。短期間で終わった検証案件や、途中で中止になった案件も含めて書き出します。中止になった案件にも、そこで得た判断の経験は残っています。

手順2：各案件を4層に分解する

並べた案件を、課題設定・データ・手法・運用の4層に割り当てます。すべての層が埋まる案件は多くありません。埋まらない層があること自体が情報で、たとえば運用の層が空欄ばかりなら、次に取る案件では運用まで担当できる条件を優先する、といった判断につながります。実績の棚卸しは、過去の整理であると同時に、次の案件選びの材料でもあります。

手順3：公開可否で三段階に仕分ける

分解した内容を、公開可・限定開示可・開示不可の三段階に仕分けます。公開可は自分のサイトや記事に書ける内容、限定開示可は経歴書や面談で出せる内容、開示不可は口にも出さない内容です。この仕分けを一度きちんとやっておくと、面談中に迷って言葉に詰まる事態が減ります。迷いながら話すと、相手には隠しごとをしている印象として伝わることがあります。

手順4：相手別に3種類の原稿を作る

仕分けた素材から、公開用・経歴書用・口頭用の3種類を作ります。同じ案件でも、公開用は手法の一般論だけ、経歴書用は担当範囲と工夫まで、口頭用は判断の理由と失敗まで、と粒度を変えます。3種類を別々に管理すると更新が大変になるので、素材は1か所にまとめ、出力先ごとに抜き出す形にしておくと維持しやすくなります。

手順5：半年に一度、見直す

技術の前提が変わると、過去の判断の説明も変わります。当時は妥当だった選択が、今の基準では説明が必要になることがあります。半年に一度、記述を読み返し、現在の技術水準から見て補足が要る箇所に一文を足します。この作業は時間がかからないうえ、面談で古い前提のまま話してしまう事故を防げます。

受注前の段階で実績づくりを仕込む

実績の見せ方は、案件が終わってからの作業だと思われがちですが、実際には受注前と着手時にできることのほうが効果が大きくなります。

契約時に公表条件を確認する

前述のとおり、契約時に顧客名の公表可否と、抽象化した言及の可否を確認しておきます。多くの場合、顧客名は不可でも業種レベルの言及は可、という回答になります。この一往復のやり取りを記録として残しておけば、後から根拠を示せます。確認を怠ると、公表してよいかどうか自分で判断できず、結局すべてを伏せることになります。

着手時に自分用の作業記録を始める

案件の初日から、判断の記録を自分用に残します。顧客の資料をコピーするのではなく、自分がその日に何を決めたかを短く書き留めるだけです。データの分割方法を決めた日、評価指標を合意した日、モデルの方針を変えた日。これらの日付と理由が残っていると、後から実績を書くときの解像度が段違いになります。

納品時に成果の言語化を顧客と共有する

納品の報告書を書くとき、技術指標だけでなく業務上の変化も言葉にしておくと、顧客側の理解が深まり、同時に自分の実績記述の下書きにもなります。報告書は顧客の所有物なので持ち出せませんが、そこで使った言い回しは自分の頭に残ります。何が価値だったかを顧客と同じ言葉で確認しておく作業は、次の依頼にもつながります。

市場の見え方と、記録を残す習慣

機械学習開発の需要は、実証実験の段階から業務適用の段階へ移りつつあります。公開されている実証事例を見ても、技術の目新しさではなく業務効果で評価される流れが読み取れます。

【参考事例】 VAAK：店舗での不審行動や万引行動を検知するシステム「VAAKEYE」を提供。実際に大手小売店舗での実証実験では77％以上の万引き被害額削減、96％以上の万引き対策時間削減という結果が出ており、2018年12月にはサービスによる検知した万引き犯逮捕に繋がるなどの結果も出ている。出典: sorabatake.jp

被害額の削減と対策時間の削減という、業務側の言葉で成果が語られている点に注目してください。実績を書くときの語彙も、これに寄せると伝わりやすくなります。技術者同士の会話では技術指標が通じますが、発注の決裁をする側には業務指標のほうが届きます。

在宅ワークや業務委託の市場を20年見てきた運営者の立場から言えば、継続的に依頼を受けている人ほど、実績を「作品集」ではなく「判断の記録」として持っています。何を選び、何を捨て、なぜそう決めたか。この記録がある人は、初対面の相手にも短時間で技能を伝えられます。逆に、成果物のスクリーンショットだけを集めている人は、それを出せない案件が増えるほど説明が苦しくなります。機械学習開発は、まさに成果物を出せない案件が多い領域です。

もう一点、運営者として見てきた限りでは、仲介手数料が差し引かれない直接取引の場では、受け手の説明の仕方が変わります。中間に立つ人が経歴を要約して先方へ渡す形式だと、要約の過程で判断の理由が落ち、技術名の羅列だけが残ります。直接やり取りする場では、自分の言葉で判断の過程を説明できる人が有利になります。手数料0%の直接取引は、同じ予算で依頼側はより多くを頼め、受け手は手取りが厚くなるという構造ですが、それ以上に、伝わり方の質が変わる点が実務上は大きいと考えられます。

自分の技能が市場でどの職種区分に対応するかを把握しておくと、経歴書の書き出しが決めやすくなります。ソフトウェア開発職の報酬水準の考え方はソフトウェア作成者の年収・単価相場にまとめられており、実績を提示する相手の期待水準を推し量る材料になります。また、案件の説明資料や報告書を自分で作る機会が多い職種でもあるため、文書作成の基礎を体系的に確認したい場合はビジネス文書検定の出題範囲が参考になります。

海外の発注元とやり取りする場合は、実績の書き方の作法が国内と異なります。英語圏では担当範囲と成果を箇条書きで簡潔に示す形式が一般的で、その進め方はUpworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法で具体的に解説されています。国内案件と併走する場合は、同じ実績を2つの形式で用意しておくと使い回しが効きます。

最後に、実績づくりを継続する仕組みについて触れておきます。案件が終わるたびに、次の4項目だけを記録します。解いた問題の抽象化した記述、選んだ手法と選ばなかった手法、詰まった点とその解き方、運用に載せた後に起きたこと。この4項目があれば、経歴書も面談も公開記事も、そこから派生させられます。出せない仕事を抱える職種ほど、記録の設計そのものが仕事の一部になります。

よくある質問

Q. 守秘義務がある案件を経歴書に書くこと自体が違反になりますか？

契約書の秘密保持条項の範囲によります。多くの契約では、開示された情報の内容が保護対象であり、業種や技術要素まで伏せた抽象的な記述は許容される場合があります。ただし顧客名の記載や、事業内容が特定できる記述は事前承諾が必要になることが一般的です。判断に迷う場合は契約締結時に公表可否を確認しておき、終了後に問い合わせる手間を避けるのが確実です。