AI・セキュリティ支援のポートフォリオの作り方｜見る人が知りたいこと

2026年5月24日

丸山桃子

この記事のポイント

✓AI・セキュリティ支援のポートフォリオは
✓守秘義務があるため実績をそのまま出せません
✓見る人が知りたい4点の整理

AI・セキュリティ支援のポートフォリオを作ろうとして、手が止まる人は多いです。理由ははっきりしていて、この領域は実績のほとんどが守秘義務の対象になるからです。診断した会社名も、見つけた脆弱性も、報告書の中身も出せません。では何を載せればいいのか。ここでは、見る人が実際に知りたがっていることから逆算して、出せる材料だけでポートフォリオを組み立てる手順を整理します。

この領域のポートフォリオが難しい理由

デザインやライティングであれば、作ったものをそのまま並べれば伝わります。この領域では、その方法が使えません。難しさの構造を先に分解しておくと、何を作るべきかが見えてきます。

実績の大半が出せない

セキュリティ支援の契約には、ほぼ例外なく秘密保持の条項が入ります。対象は、依頼側の名称、システム構成、発見した問題、報告の内容と、およそ実績と呼べるもの全部です。しかも秘密保持の義務は契約終了後も一定期間続くのが通常なので、時間が経てば出せるという性質のものでもありません。

さらに厄介なのが、セキュリティ支援では「どこを見たか」という情報自体が機微になる点です。攻撃者にとっては、どこが見られていないかの手がかりになるからです。だから、依頼側の許可があっても書けないことが残ります。この前提を無視して具体的に書いてしまうと、業界内での信用を一気に失います。

成果が「何も起きなかったこと」として現れる

もう一つの難しさは、成果の性質です。この仕事の成果は、問題が起きなかったという事実として現れます。起きなかったことは、数えられません。

デザインなら「サイトのデザインを刷新した」と見せられますし、開発なら動くものを見せられます。セキュリティ支援は、うまくいくほど何も見えなくなります。この非対称性を理解した上で、成果ではなく過程を見せる方向に切り替える必要があります。

見る人が技術者とは限らない

ポートフォリオを読むのが誰かを考えると、構成が変わります。AI関連のセキュリティ支援を依頼したい組織の窓口は、情報システム部門とは限りません。事業部門の担当者、経営企画、法務、総務。AI導入の旗振り役が、必ずしも技術者ではないケースが増えています。

技術者向けの記述だけで固めると、非技術者の読み手が判断できません。判断できないものは、社内で推薦されません。かといって、非技術者向けだけにすると、技術者が読んだときに中身が薄く見えます。両方に届く構成が必要です。

比較の対象が法人になる

個人で活動する場合、読み手は無意識に法人のサービスと比較しています。組織であれば、体制、実績数、保険、代替要員といった安心材料を並べられます。個人にはそれがありません。

ここで対抗しようとして、実績を盛ったり範囲を広く見せたりするのは逆効果です。読み手は比較に慣れているので、無理のある記述はすぐ分かります。個人が勝てるのは、対応の速さ、窓口が一本であること、担当者が変わらないことです。この三点は法人にはない強みなので、明示的に書きます。

同時に、個人であることの限界も書きます。同時に受けられる案件の数には上限があること、大規模な体制が必要な案件には向かないこと。限界を書いておくと、合わない相談が減り、合う相談だけが来ます。読み手の側も、判断の材料が増えて助かります。

見る人が知りたいこと

守秘義務があるからと言って、載せられるものがないわけではありません。読み手が知りたいことから逆算すると、書けることは意外に多いです。読み手の関心は、大きく四つに整理できます。

判断の質が信用できるか

技術力そのものより先に見られているのが、判断の質です。この人に任せたときに、優先順位を間違えないか。過剰に騒がず、かといって見落とさないか。

判断の質は、事例そのものではなく、判断の基準を示すことで伝わります。どういう観点で優先度を決めているか、どういう場合に対応を見送ると判断するか。この基準を言語化して書いておくと、読み手は自分の組織に当てはめて考えられます。事例が書けないなら、基準を書けばよいという発想の転換です。

説明できる人かどうか

支援を受ける組織の担当者は、支援の結果を社内で説明する立場に置かれます。だから、説明が上手い支援者を求めています。

この点は、ポートフォリオの文章そのもので示せます。専門用語を使いつつ、その用語を業務の言葉に翻訳した記述が並んでいれば、それだけで説明力の証明になります。逆に、専門用語を並べただけの記述は、説明が苦手な人という印象を残します。ポートフォリオは、実績の一覧であると同時に、文章のサンプルでもあります。

秘密を守れるか

これは見落とされがちですが、極めて重要です。守秘義務の意識が低い支援者に、機密性の高い領域を任せる組織はありません。

そして、その判断はポートフォリオそのものから行われます。過去の案件について具体的に書きすぎているポートフォリオは、それ自体が減点材料になります。「この人は、うちのことも同じように書くだろう」と思われるからです。逆に、適切に抽象化されたポートフォリオは、それだけで守秘の意識を示す証拠になります。書かないことが、実績になるという珍しい構造です。

どこまで対応できるか

範囲の把握です。診断だけなのか、方針の策定まで見るのか、実装の助言までできるのか。社内向けの説明資料まで作れるのか。

範囲を明示しておくと、問い合わせの精度が上がります。範囲外の相談が減り、範囲内の相談が増えます。曖昧にしておくと、あらゆる相談が来て、断る手間だけが増えます。できないことを書くのは弱みの開示に見えますが、実際には効率を上げる働きをします。

守秘義務を守りながら実績を書く

案件の実績をまったく書かないと、経験の量が伝わりません。抽象化して書くのが基本です。段階を追って整理します。

抽象化の三段階

第一段階は、固有名詞を業種と規模に置き換えることです。「株式会社◯◯の案件」ではなく「従業員数が数百名規模の製造業」と書きます。この段階で、依頼側の特定はほぼ不可能になります。

第二段階は、システムの記述を機能の記述に置き換えることです。「A社のB製品を使った構成」ではなく「社内文書を参照する生成AIの仕組み」と書きます。製品名を出すと、業界内では構成が推測できてしまうことがあります。

第三段階は、発見した問題を分類名に置き換えることです。具体的にどこにどういう不備があったかは書かず、「入力の扱いに関する不備」「権限設計に関する指摘」といった分類で書きます。分類なら、業界で共有されている枠組みを使えるので、読み手にも伝わります。生成AIを組み込んだシステムの脅威は、体系化された整理が公開されています。

AIシステム、特にLLMやエージェント型AIの活用は、企業に大きな可能性をもたらしています。しかし同時に、プロンプトインジェクション、機密情報漏洩、AIエージェントの自律行動を悪用したリスクなど、新たな攻撃可能面を生み出しています。これらの脅威はOWASP Top 10として体系化されており、既に実際のインシデントとして顕在化しています。出典: netone.co.jp

体系化された分類を使って書くと、具体的な情報を出さずに、扱った領域の広さを示せます。読み手も、自分の組織の課題と照合できます。

書いてよいことと悪いことの線引き

判断に迷ったときの基準を持っておきます。その記述から、依頼側が特定できるか。特定できたとして、攻撃の手がかりになるか。この二つで判断します。

業種と規模だけなら、該当する組織は多数あるので特定できません。ただし、業種と規模と地域と時期を組み合わせると、絞り込める場合があります。要素を重ねすぎないことです。また、まだ修正が完了していない問題については、分類名であっても書かない方が安全です。修正済みかどうかは、依頼側に確認しないと分かりません。

事前に許可を取る手順

抽象化しても不安が残る場合は、依頼側に確認します。確認の仕方にコツがあります。

「実績として公開してよいですか」と漠然と聞くと、たいてい断られます。判断のコストが高いからです。代わりに、実際に載せる文面を作って「この記述で公開してよいか」と聞きます。文面が具体的にあれば、相手は読んで判断するだけで済みます。承諾が得られたら、その記録をメールで残します。口頭の承諾だけだと、担当者が変わったときに根拠がなくなります。

前職の実績を扱うときの注意

会社員として担当した業務を実績に載せる場合、二重の制約がかかります。依頼側との秘密保持に加えて、前職の会社との間にも義務が残っているためです。

多くの雇用契約や退職時の誓約書には、在職中に知り得た情報の秘密保持が定められています。これは退職後も続きます。前職で担当した案件を、社名を伏せていても詳細に書くと、この義務に触れる可能性があります。特に、社内でしか知り得ない体制や手順を書くのは危険です。

安全な書き方は、担当した役割と、扱った技術領域の分類に留めることです。「事業会社の情報システム部門で、社内システムの脆弱性対応の運用に従事」といった水準です。物足りなく感じるかもしれませんが、この水準でも経験の輪郭は伝わります。詳細を書いて信用を失うより、輪郭で止めた方が結果的に得です。

自作の成果物で埋める

案件の実績が書けない部分は、自分で作ったもので埋めます。この領域では、自作の成果物の方が説得力を持つ場面が少なくありません。

報告書のサンプルを作る

架空のシステムを想定して、実際に納品するのと同じ形式の報告書を作ります。表紙、要約、指摘の一覧、優先順位、推奨する対応、残るリスクの扱い。実際の案件と同じ構成にします。

これが最も効く成果物です。理由は、依頼側が最も知りたいのが「どういう成果物が納品されるのか」だからです。文章の質、構成の分かりやすさ、非技術者への配慮。すべてがこのサンプル一つで伝わります。守秘義務にも一切触れません。作るのに時間はかかりますが、投資対効果は高いです。

サンプルを作るときは、経営層向けの要約を必ず入れます。技術的な指摘だけの報告書は、実務では使いにくいものです。要約が入っているサンプルは、それだけで「分かっている人」の印象を与えます。

チェックリストやひな型を公開する

社内のAI利用ガイドラインのひな型、導入前の確認事項をまとめたチェックリスト、リスクの評価シート。こうした汎用的な成果物を作って公開します。

公開すると使われます。使われると問い合わせが来ます。実際、こうした汎用の成果物が入口になって相談に繋がるケースは珍しくありません。作るときは、そのまま使える完成度にします。中途半端なものを出すと、逆の印象を与えます。

検証環境を作った記録を残す

自分で脆弱な構成を作り、そこで検証した記録を残す方法もあります。生成AIを組み込んだ簡単な仕組みを作り、入力の扱いに問題がある状態と対策した状態を比較する。この過程を記録します。

この記録の価値は、手を動かせることの証明にあります。理屈を知っているだけの人と、実際に構成を組んで確認できる人は違います。自分で作った環境なので、公開に何の制約もありません。技術的な読み手には、これが最も響きます。

技術記事や資料を蓄積する

調べたことを記事にまとめて公開する形も有効です。新しい脅威の整理、公表された脆弱性の解説、標準や指針の読み解き。継続的に書いていると、追い続けている人だという証明になります。

この領域は変化が速く、対象そのものが急速に広がっています。

現在、AIエコシステムはサイバーセキュリティの観点から重大なリスク要因となりつつあります。TrendAI™ Researchは、330,239件の脆弱性（CVE）を分析し、2018年から2025年の間にAIシステムに直接影響する6,086件の固有の脆弱性が公開されていることを確認しました。その推移は図1に示されています。出典: trendmicro.com

これだけの量が公表されている領域で、情報を追い続けていることを示せるかどうかは、依頼側にとって重要な判断材料です。記事の本数より、更新が続いていることの方が効きます。半年前で止まっている記事一覧は、逆の印象を与えます。

学習の過程も材料になる

経験が浅い段階では、自作の成果物すら十分に用意できないことがあります。その場合、学習の過程そのものを記録として残す方法があります。

何を、どういう順番で、どういう教材で学んだか。学ぶ中で分からなかったこと、それをどう調べて解決したか。この記録は、実務経験の代わりにはなりませんが、学び方の質を示します。この領域は知識の更新が前提になる仕事なので、学び方が確立している人は評価されます。

実際に手を動かした痕跡があると、さらに効きます。読んだだけの記録と、環境を作って試した記録では、重みが違います。小さくてよいので、必ず動かして確認した記録を残します。書籍を読んで理解した内容と、実際に動かしてみて想定と違った点を並べて書くと、それだけで実務的な姿勢が伝わります。

構成と見せ方

材料が揃ったら、並べ方を考えます。読み手は時間をかけて読みません。最初の画面で判断されます。

冒頭に置くもの

最初に置くのは、対応できる範囲の要約です。どういう業務を、どういう規模の組織に対して提供できるか。三行から五行にまとめます。

その次に、代表的な成果物のサンプルへのリンクを置きます。報告書のサンプルが最初に目に入る配置にします。実績の一覧は、その後で構いません。読み手が最初に確認したいのは「何を作ってくれるのか」であって、「どこと仕事をしたか」ではないためです。

自己紹介を長く書くのは避けます。経歴の羅列は読まれません。経歴は、対応範囲の裏付けとして必要な部分だけを短く書きます。

案件ごとの記述形式を統一する

抽象化した実績を並べるときは、形式を揃えます。業種と規模、支援の目的、担当した範囲、使った手法の分類、成果の形。この五項目を毎回同じ順で書きます。

形式が揃っていると、読み手は比較しながら読めます。バラバラだと、一件ずつ読み解く負担が発生し、途中で離脱されます。項目を揃えることは、読み手への配慮であると同時に、自分の業務を分類して把握する訓練にもなります。

対応できる技術の書き方

技術の一覧を並べるとき、名前だけを羅列しないことです。「触ったことがある」と「業務で使える」の区別がつかないためです。

区別を明示します。中心的に扱っている領域、業務で使用した経験がある領域、把握はしているが実務経験は少ない領域。この三つに分けて書きます。正直に分けて書いた方が、信用されます。全部を同列に並べると、読み手は全体を割り引いて受け取ります。

分量の目安

長すぎるポートフォリオは読まれません。ただし、短すぎると経験の量が伝わりません。

現実的なのは、概要のページを一枚に収め、詳細は別のページに分けて置く構成です。概要のページは、スクロールせずに読み切れる分量にします。関心を持った読み手だけが詳細に進みます。この構造にすると、非技術者と技術者の両方に対応できます。概要で判断する人と、詳細まで読む人が分かれるからです。

置き場所と見せ方の選択

ポートフォリオをどこに置くかも、判断が必要です。自分のサイトを持つ、記事の投稿サービスを使う、資料を配布する形にする。それぞれ性質が違います。

自分のサイトは、構成を自由に組めますし、更新の記録も残せます。手間はかかりますが、この領域では管理できていること自体が信用の材料になります。逆に、放置されて更新日が古いまま残っているサイトは、逆効果になります。

資料の形で配布する方式は、相談があった段階で渡せる利点があります。公開する必要がないので、抽象化の程度を相手ごとに調整できます。ただし、検索から見つけてもらう入口にはなりません。両方を用意し、公開用は控えめに、個別に渡す資料は詳しくという二段構えにするのが実務的です。

もう一つ、掲載する連絡先の扱いにも注意が必要です。この領域では、支援者自身が標的になる可能性があります。過剰に個人の情報を出さず、連絡は問い合わせの窓口に一本化しておく方が安全です。この配慮ができていること自体も、読み手には伝わります。

見せてはいけないもの

作り込むほど、載せたくなるものが増えます。避けるべきものを挙げておきます。

使用しているツールの具体的な設定内容、検証に使ったスクリプトのうち攻撃の再現に直接使えるもの、まだ修正されていない問題に関する記述、依頼側の担当者が特定できる情報。これらは、載せた瞬間に評価が反転します。

判断に迷ったら、載せないという原則で運用します。この領域では、情報を出さないことによる機会損失より、出したことによる信用の毀損の方がはるかに大きいためです。実際、抽象度の高いポートフォリオでも問い合わせは来ます。むしろ、丁寧に抽象化されていることが選ばれる理由になっている場面をよく見ます。

名前と顔をどこまで出すか

実名で活動するか、屋号だけにするかという判断もあります。信用の面では実名の方が有利ですが、この領域では個人が標的になる可能性を考慮する必要があります。

現実的なのは、実名は出すが、所在や連絡手段は絞るという形です。氏名と対応範囲は明示し、住所や個人の携帯番号は出さない。写真については、載せると親しみは増しますが、必須ではありません。載せない選択をしても、成果物の質が伝われば問い合わせは来ます。この判断に正解はないので、自分が長く運用できる形を選びます。

更新の運用を決めておく

作って終わりにすると、半年で古くなります。特にこの領域は動きが速いので、更新が止まっているポートフォリオは実務から離れた印象を与えます。

更新のタイミングを決めておきます。案件が一つ終わるたびに、抽象化した記述を追加する。四半期ごとに、対応範囲の記述を見直す。年に一度、全体の構成を見直す。この三つの周期を回すと、放置されません。

案件が終わった直後に書くのが重要です。時間が経つと、何をどう判断したかの記憶が薄れます。終了時に十五分だけ時間を取り、業種と規模、目的、範囲、手法の分類、成果の形の五項目をメモしておきます。公開用に整えるのは後でよく、素材だけ残しておけば十分です。

問い合わせから逆算して改善する

作った後は、実際に来た問い合わせを見て手を入れます。ポートフォリオの良し悪しは、閲覧数ではなく問い合わせの質で測ります。

来た相談が範囲外のものばかりなら、対応範囲の記述が伝わっていません。相談の内容が漠然としているなら、こちらが扱う課題の具体例が足りていません。相談は来るが条件が合わないなら、想定している規模感の記述が不足しています。

問い合わせが一件来るたびに、その人がどの記述を読んで連絡してきたかを聞きます。多くの人は答えてくれます。答えを集めると、実際に効いている記述と、読まれていない記述が分かります。読まれていない部分は削ります。削って短くなったポートフォリオの方が、たいてい成果が上がります。

職種の枠組みから自分の位置を確認する

ポートフォリオを作る過程で、自分がどの職種として見られたいのかがはっきりしてきます。ここが定まっていないと、記述の焦点がぼやけます。

AIの導入方針や社内での活用ルールの設計を主軸にするなら、AIコンサル・業務活用支援のお仕事の枠組みに近い立ち位置です。この場合、ポートフォリオには技術的な検証より、判断の基準や資料の作り方を厚く載せます。読み手が非技術者になる比率が高いためです。

実装に近い領域を扱うなら、AIチャットボット・アプリ開発のお仕事の側に寄ります。この場合は、検証環境を作った記録や、実際に手を動かした痕跡を厚くします。読み手に技術者が含まれる比率が高くなるためです。

職種としての市場での位置づけを確認したいときは、ソフトウェア作成者の年収・単価相場にデータがまとまっています。自分が向かおうとしている方向が、市場でどう扱われているかを把握しておくと、ポートフォリオの重心を決めやすくなります。

体系的な知識を持っていることを示す材料として、資格を載せる選択肢もあります。生成AIパスポートは、AIの基礎的な用語や活用時の留意点を体系的に押さえるもので、非技術者との共通言語を持つ根拠になります。ただし、資格の一覧だけが並んだポートフォリオは中身が薄く見えます。資格は、対応範囲の裏付けとして短く添える程度に留めます。

在宅ワーク市場から見えるデータ考察

在宅・業務委託の市場を長く運営してきた立場から見ると、問い合わせに繋がるポートフォリオには共通点があります。実績の量が多いことではなく、読み手が自分の状況を当てはめられる記述になっていることです。

具体的には、「こういう状況の組織で、こういう相談を受けることが多い」という書き方をしているものが強いです。読み手は、自分の組織がその記述に当てはまるかどうかで判断します。逆に、自分の技術力を並べただけのポートフォリオは、読み手が自分の状況と接続できないので、問い合わせに至りません。

運営者として見てきた限りでは、直接取引の場ではこの傾向がさらに強く出ます。仲介が入る形だと、条件で絞り込まれた後に人が比較されますが、直接の場では、読み手が自分で相談先を選びます。だから、読み手が「これはうちの話だ」と思える記述が決定的に効きます。中間マージンが乗らない手数料0%の直接取引では、依頼側は同じ予算でより多くを頼めますし、受け手の手取りも厚くなります。それ以上に効くのは、最初の接触の時点で相手が課題を持って来てくれることです。課題を持った相談は、話が早く、条件も整理しやすくなります。

AI領域は、依頼側も何を頼めばいいのか手探りの状態にあります。だからこそ、ポートフォリオに「こういうことができます」だけでなく「こういう場面で相談されることが多いです」と書いてある人が選ばれています。実績が出せないことを嘆くより、読み手の状況に接続する記述を増やす方が、結果に直結します。AI案件の獲得から実務までの流れはフリーランス AI案件の獲得術！生成AI時代に年収を倍増させる戦略に、開発寄りの案件の実態はAIチャットボット開発のフリーランス案件｜必要スキルと単価にまとまっています。

守秘義務は制約であって、不利ではありません。制約の中で何をどう見せるかを設計できること自体が、この領域では能力の証明になります。書けないことを丁寧に扱っている人は、それだけで信用されます。

よくある質問

Q. 守秘義務があって実績が書けません。何を載せればよいですか？

抽象化して書きます。固有名詞は業種と規模に、製品名は機能の記述に、発見した問題は体系化された分類名に置き換えます。加えて、案件の実績とは別に自作の成果物を用意します。架空のシステムを想定した報告書のサンプル、ガイドラインのひな型、検証環境を作った記録などです。これらは守秘義務に一切触れず、しかも判断の質や説明力を示せます。

Q. ポートフォリオで最も効く成果物は何ですか？

実際の納品物と同じ形式で作った報告書のサンプルです。依頼側が最も知りたいのは、どういう成果物が納品されるのかという点だからです。表紙、要約、指摘の一覧、優先順位、推奨する対応、残るリスクの扱いまで、実案件と同じ構成にします。経営層向けの要約を必ず入れると、実務を分かっている印象が伝わります。

Q. 案件の実績を公開する許可はどう取ればよいですか？

漠然と「実績として公開してよいか」と聞くと、判断のコストが高いため断られやすくなります。実際に載せる文面をこちらで作成し、「この記述で公開してよいか」という形で確認します。相手は読んで判断するだけで済みます。承諾が得られたら、その記録をメールで残します。口頭だけだと担当者の交代で根拠がなくなります。