ゲーム以外のポートフォリオに載せる制作物ページ：課題・判断・AIの使いどころの整理

書く項目は5つに絞る

完成物のスクリーンショットと機能一覧だけでは、読み手は「どこまで本人がやったのか」を判断できません。次の判断表のとおりに項目を分けると、書くことが決まります。

• 課題、書くこと：誰の、どんな場面の困りごとか。今回は扱わないと決めた範囲、避けたいこと：「便利なツールを作りたかった」だけの動機
• 仕様判断、書くこと：選択肢が複数あった点と、選んだ理由、捨てたもの、避けたいこと：できた機能の羅列
• AIに任せた範囲、書くこと：作業ごとのAIの役割と、自分の関与、避けたいこと：「AIが全部やった」「自力で作った」の一言
• 直した点、書くこと：AIの出力や自分の初版の問題、見つけ方、直し方、再確認の方法、避けたいこと：「修正しました」だけの記述
• 現状と限界、書くこと：確認した環境、未対応の点、次の予定、避けたいこと：測っていない効果や利用者数

この中で最も差がつくのは「仕様判断」と「直した点」です。AIが出した案をそのまま採用した場合でも、「他の案と比べてこれを選んだ」と書けるなら、それはあなたの判断です。反対に、判断した覚えがないなら、制作中に選んだ場面を思い出して拾い直してください。

制作物ページの雛形

次のMarkdownをそのままコピーして埋めてください。Markdownなら、GitHubのREADMEにも使えます。GitHubのドキュメントでは、READMEはプロジェクトの有用性やできること、使い方を伝えるファイルで、一般にプロジェクトの機能、有用性、始め方、サポート、メンテナーや貢献者の情報を含むと説明されています（About the repository README file）。下の雛形は、その項目に「判断」と「AIの範囲」を足したものと考えてください。

# 制作物名
一言説明：誰の、どんな困りごとを、何で解決するか（1文）

公開URL： / ソースコード： / 制作期間： / 使用技術：

## 1. 課題
- 困っていた人・場面：
- 既存の方法で足りなかった点：
- 今回はやらないと決めたこと：

## 2. 仕様判断
| 判断したこと | 選択肢 | 選んだ理由 | 捨てたもの |
|---|---|---|---|
|  |  |  |  |

## 3. AIに任せた範囲
| 作業 | 使ったAI・使い方 | AIの出力 | 自分がやったこと |
|---|---|---|---|
|  |  |  |  |

## 4. 直した点
| 問題 | 見つけ方 | 直し方 | 直した後の確認 |
|---|---|---|---|
|  |  |  |  |

## 5. 現状と限界
- 確認した環境（ブラウザ・端末）：
- 未対応・既知の問題：
- 次にやること：

表が重ければ、箇条書きでも構いません。大切なのは、各欄に「自分がやったこと」と「確認の方法」が入っていることです。

記入例（説明用の例）

以下は雛形の使い方を示すために作った架空の例です。実在する制作物でも、実際に動作確認した結果でもありません。

制作物：割り勘の端数メモ（架空）一言説明：サークルの飲み会で、1円単位の端数を誰が持つかを決めて記録する、1画面のWebツール。

• 課題：表計算シートだと端数の扱いが人によってばらつく。決済アプリ連携はやらないと決めた。
• 仕様判断の例：端数の処理を「幹事が持つ」「ランダム」「順番」の3案で比べ、「前回の担当者の次の人が持つ」を選んだ。理由は、毎回のやり取りで不満が出にくいと考えたから。ランダムは説明しにくいので捨てた。
• AIに任せた範囲の例：画面の初版コードの作成はAIに任せた。端数の配分ルールは自分で文章にして渡した。
• 直した点の例：人数を0にすると計算結果が「NaN」と表示された。入力欄を数字だけに限定し、0以下ならメッセージを出すように直した。直した後に、0、1、100人、全角数字を入力して表示を確認した。

ここで見てほしいのは、数値の成果が一つも出てこないことです。本当に測っていないなら、書かないのが正解です。「直した後の確認」は、実際に自分がやった操作だけを書きます。

作業ログから下書きを作る依頼文

制作中に、次の3つだけメモしておくと後で書くのが楽になります。

1. AIに頼んだ内容と、返ってきた結果で気づいたこと
2. 迷って選んだ点（選択肢と理由）
3. エラーや違和感を見つけた場面と直した内容

制作が終わってから、このメモをAIに渡して整理させます。

以下は、私が作ったWebツールの制作メモです。
制作物ページの下書きを、次の見出しで作ってください。
見出し：課題／仕様判断／AIに任せた範囲／直した点／現状と限界

ルール：
- メモに書かれていないことは推測せず、「要確認：○○」と書く。
- 利用者数、時間短縮、満足度などの数値や成果は書かない。
- 「AIが」「私が」の主語をはっきり分ける。
- 判断の理由がメモにない箇所は、私に質問を出す。

【制作メモ】
（ここに貼り付ける）

この依頼文の狙いは、AIに文章を飾らせることではなく、不足している情報を「要確認」として洗い出させることです。出てきた下書きは、あなたの記憶とログに照らして1行ずつ確認し、事実と違う箇所を直してください。

メモを貼る前に、APIキー、パスワード、個人情報、他人から預かったデータは消すか、ダミーに置き換えます。AIサービスの学習利用の設定と、情報を外部に出さないこと（秘密保持）は別の話です。学習に使われない設定にしても、貼った内容を第三者に見せてよいことにはなりません。

公開前の確認

下書きが整ったら、公開前に次の点を見ます。

• AIの出力をそのまま載せていないか：画像やコードが既存の作品や他の制作物に似ていないか確認します。文化庁は、AIと著作権について「AIと著作権に関する考え方について」（2024年3月15日）や、2024年7月31日のチェックリスト＆ガイダンスなどを公開しています（文化庁「AIと著作権」）。日本の著作権制度に関する資料なので、海外向けに公開する場合や個別の判断が必要な場合は、原資料や専門家に当たってください。
• スクリーンショットに代替テキストを付けたか：MDNは、画像のalt属性を、読み上げソフトや画像が表示されない場面で画像の代わりになるテキストと説明しています（MDN: img要素）。「image」のような一語ではなく、「割り勘結果が3人分表示された画面」のように、前後の文と合わせて意味が通る内容にします。
• 他人の情報が写っていないか：入力例の名前、店名、画面上の通知を確認します。
• 書いた確認を本当にやったか：「直した後の確認」に書いた操作は、公開前にもう一度実行してみます。
• AIの範囲に偏りがないか：全部を「AIが」と書くと判断が見えず、全部を「自分が」と書くと実態と離れます。作業ごとに分けて書いてください。

書き終えたときの見直し

最後に、ページを次の3つの問いで読み直してください。

1. 「課題」を読んだ人が、このツールを使う場面を想像できるか
2. 「仕様判断」に、捨てた選択肢が1つ以上あるか
3. 「直した点」に、直した後の確認方法が書かれているか

この3つが満たせていれば、AIをどれだけ使ったかにかかわらず、制作の過程と判断がページから読み取れます。