AIで作ったポートフォリオが評価されるかは、AIを使ったかどうかよりも、作ったものを自分の言葉で説明でき、動いたあとに確かめ、壊れたら直せるかで分かれると、編集部は考えています。作れることと、壊さずに動かし続けられることは別です。
先に結論：評価が分かれる5つの線
| 観点 | 評価されにくい | 評価されやすい |
|---|---|---|
| 説明 | 「AIが作りました」で終わる | 選んだ理由と、採らなかった案を自分の言葉で話せる |
| 確認 | 動いている画面だけがある | 件数・権限・本番での動作を確かめた記録がある |
| 運用 | 作って終わりで、更新の跡がない | 公開して動かし続け、不具合と直した経緯が残っている |
| AIの扱い | 触れない、またはすべてをAIの成果として書く | AIに任せた範囲と、自分で決めた範囲を分けて書く |
| 範囲 | 機能の数と見た目の説明が中心 | 小さくても、担当範囲・判断の理由・改善による変化が読める |
採用側がポートフォリオで確かめたいこと
JACリクルートメントのポートフォリオ解説（2026年4月）によると、採用側は限られた時間で候補者を比較するため、必要な情報にすぐ辿り着けるかを重視します。ポートフォリオは、職務経歴書では分かりにくいコードの品質、設計の考え方、事業への影響を補う資料として見られます。
- 技術名の列挙より、担当範囲、判断の理由、改善による変化が示されているか
- GitHubでは、READMEの分かりやすさ、コミットやPRの履歴、テストやCIの有無から、品質と進め方を判断する
- 未経験者は学び方と基礎の積み上げ、経験者は再現性のある成果と意思決定が見られやすい
- 面接では、設計判断やトレードオフの議論に入りやすくなり、質問は性能改善、障害時の切り分け、変更に強い構成などに広がる
AIで作った場合も、同じ観点で見られると考えるのが自然です。
理由は2つあります。1つ目は、企業がAI活用を評価に入れ始めていることです。
ファインディが2025年7月に、同社の転職サービスなどの利用企業220社に聞いた調査（ITmedia報道）では、AIの活用経験の有無を候補者の評価で「重視している」と答えた企業が57.0%で、2025年2月の前回の18.1%から増えました。AIを使うこと自体は、避ける対象になっていません。
2つ目は、「説明できない」ことが問題として起きていることです。キッカケクリエイションが2026年2月24〜27日に、業務でコードレビューを担当するITエンジニア322名に行った調査では、AI生成コードのレビュー経験がある277名が最も多く挙げた問題が、「提出者本人がコードの内容を説明できなかった」で、49.5%でした（上位3つまでの複数回答）。
採用側が、提出物の中身を本人が分かっているかを気にする理由になると考えられます。
動いたのに壊れた：運営会社の実例5件
運営会社は、採用領域のSaaS、営業メッセージの自動送信ツール、データベースを持つWebメディアなどを、Claude Codeなどのコーディングエージェントと一緒に作り、本番で運用しています。
AIは、コードを速く書けました。一方で、「動いた」で確認を終えた部分が、あとから事故になりました。
| 起きたこと | 動いていた理由 | ポートフォリオに置き換えると |
|---|---|---|
| データの取得が既定の上限（1,000件）で黙って切れ、送付済みの宛先の除外が漏れて、同じ宛先に二重送信した | エラーも警告も出ず、コードは正常に動いた | 取得した件数を、総数と突き合わせた記録 |
| 権限の漏れが、本番まで見つからなかった | 開発環境が管理者権限で動き、手元では全部通った | 別のユーザーで本物のログインをして試した記録 |
| ページの表示が1秒近くかかった | クエリ単体の計測は速く、原因は実行場所とDBの距離だった | 公開した環境での、表示速度の計測 |
| 検索エンジンのクロールが、2日でほぼ止まった | 作成済みのページは速く、目視では気づけなかった | 公開後に、検索エンジンやアクセスの統計を見た記録 |
| 失敗を消す修正で、品質の劣化が外に出た | エラーは止まり、直ったように見えた | 直したあとに、結果の質を測り直した記録 |
5件に共通するのは、画面や実行結果が正しく見えたことです。AIが書いたコードは、手元では動いていました。
差が出たのは、動いたあとに、件数、権限、本番、品質を自分で確かめたかどうかでした。1件ずつの原因と防ぎ方は、AI開発の失敗事例9つに書いています。
ポートフォリオでも同じことが言えます。動く画面は、AIが数時間で作れます。
採用側が知りたいのは、その先にある「確かめた記録」と「壊れたときの直し方」だと、編集部は考えています。
AIが書いたコードは、安全とは限らない
動くことと、安全なことも別です。セキュリティ企業のVeracodeは2025年7月、80の課題について100を超える大規模言語モデルにコードを書かせ、結果を公表しました。
安全な書き方と危険な書き方の両方がある課題で、モデルが危険なほうを選び、OWASP Top 10に分類される脆弱性が入ったのは、全体の45%でした。クロスサイトスクリプティングへの対策が漏れたのは86%のケースで、モデルが大きくなっても、安全性は目立って改善していませんでした。
この数字は、決まったテストの結果で、実際に出回っているコード全体の45%という意味ではありません。それでも、ログインや決済、個人情報を扱う作品ほど、動作確認とは別に、確かめる項目が要ることは分かります。
作れたことと、分かっていることは別
AIで作れたことと、自分が理解していることも、別のことです。Anthropicが2026年1月に公表した実験では、Pythonの非同期処理ライブラリを初めて使うソフトウェアエンジニア52人（多くは経験の浅い人）を、AIありとなしに分けて課題を解かせ、そのあとの理解度テストを比べました。
平均はAIありが50%、なしが67%で、差が最も大きかったのはデバッグの問題でした。
AIありの中でも、コードの記述を全部任せた人は低く、コードを生成させたあとに質問して理解を深めた人や、概念を質問して自分で直した人は高い点でした。人数が少なく、直後の理解度だけを測った予備的な結果で、Anthropic自身も、AIの使い方と理解度の因果関係までは示せないとしています。
学ぶ側にとっての使いどころは、次のとおりです。作ったあとに、AIへ「なぜこう書いたのか」「ここが間違っていたらどうなるか」を質問し、答えを自分の言葉で書き直します。
それがそのまま、READMEの「判断の理由」になります。
「AIで作った」と書くべきか
選考によって、扱いが違います。
- 申告が条件のところがあります。Cygamesの新卒選考は、提出するプログラミングのソースコードについて、制作過程の補助的なAI利用に限り認め、使ったツール名と利用内容を明記するよう求めています。規定を外れた提出物があれば、選考資格を失うと定めています
- 透明性を求めるところがあります。Anthropicの応募者向け案内は、AIを使った場合の透明性を、望むことの1つに挙げています
- 採用側の悩みもあります。カミナシのエンジニアブログは、持ち帰り課題について、AI以降は提出物から本人の寄与が読み取れなくなったと書いています
AIに任せた範囲と、自分で決めた範囲を分けて書くことは、採用側の悩みを減らし、面接の話題にもなります。
提出先の案内に、AI利用の規定がないかを先に確認してください。
READMEに足す5つの記録
ポートフォリオのREADMEに、次の5つを足します。JACの解説が挙げる、READMEの分かりやすさ、担当範囲、判断の理由、改善による変化に対応します。
- 何を作り、誰がどう使うか：2行で書きます
- AIに任せた範囲と、自分で決めた範囲：分けて書きます。自分で決めたものには、理由を一言添えます
- 確かめたこと：取得した件数と総数の一致、別のユーザーでの権限の確認、公開した環境での動作と表示速度を書きます。認証や入力フォームがあるなら、入力の扱いの確認も加えます。自動テストが1本でもあれば、場所を示します
- 起きた不具合と、直し方：1件でも書きます。AIが間違えた箇所があれば、どう気づいたかも書きます
- 動かし続けている記録：公開日、更新の履歴、止まったときに気づく仕組み、毎月かかる費用を書きます。AIのAPIを使うなら、1か月の上限金額も決めておきます
現役のエンジニアが個人のプロダクトを見せる場合は、5番の重みが増すと考えます。JACの解説は、経験者には再現性のある成果と意思決定が見られやすいと書いています。
稼働期間、障害と対応、費用の推移が残っていれば、「作った」より先の経験が伝わります。
未経験の人が2週間で整えるなら
日数は目安です。
- 1〜3日目：小さなものを1つ作り、公開します。AIは使って構いません
- 4〜7日目：件数、権限、本番での動作の3つを自分で確かめ、結果をREADMEに書きます
- 8〜10日目：AIを使わずに、小さな変更を1つ自分の手で入れます。機能の追加か、不具合の修正です。やり方もREADMEに残します
- 11〜14日目：3分で説明する練習をします。なぜその技術を選んだか、AIが間違えたのはどこか、次に壊れそうなのはどこか、の3つを声に出します
学び方の順番を整理した記事は、プログラミングを学ぶ意味はAI時代にもあるかにあります。
