プログラミング 初心者 作品 アイデア｜公開URLまで作る実践ガイド
要約
プログラミング 初心者 作品 アイデアとして、1週間以内に終わり公開URLが残るものを5つ紹介します。公開APIを使うダッシュボード、自分のAPI、AI要約、意図的な障害テストを扱います。各作品で、タイムアウト、キャッシュ、ヘルスチェック、環境変数、構造化ログを実践します。チュートリアルの写経だけの作品は避け、ひとつ選んで本番に公開し、ひとりに見せることを勧めます。
プログラミング 初心者 作品 アイデアとして最も効果が高いのは、1週間以内に終わり、最後に公開URLが残るものです。公開APIを使う天気ダッシュボード、自分で作る小さなREST API、ヘルスチェック付きのブックマークサービス、そして意図的に壊して直すプロジェクトを紹介します。チュートリアルの写経だけで終わるものは避けてください。ひとつ選んで本番環境に公開し、実際にひとりへ見せるところまでを目標にします。
火曜日の午後2時40分、ある学習者がDiscordにこう書き込みます。「ToDoアプリは手元では動きます。どうすれば公開できますか？」。その後1時間、誰も返信しません。「手元で動く」と「他人が使える」の間にあるこの溝で、多くの初心者プロジェクトは止まってしまいます。このリストは、その溝を埋めるために作りました。
なぜ初心者の作品には公開URLが必要なのか
手元のリポジトリは、手順どおりに進められたことを示すだけです。公開されたサービスは、設定、シークレット、ポート、ビルド、そして障害への対応を同時に扱えたことを示します。実務で求められるのは、こちらのほうです。
Sigma Schoolの初心者向けガイドも、最初のプロジェクトは公開URLで終えるべきだと説いています。公開URLをひとりに見せるほうが、未完成のリポジトリを3つ持つより価値があるという主張です。私たちもこの点には同意しますが、ひとつ補足します。URLは最低ラインであり、ゴールではありません。ゴールは、障害が起きたときに説明できるプロジェクトを持つことです。
このリストの各アイデアには、次のフィルターを適用しています。10時間以内に作れるか。公開APIを呼び出すか、または公開しているか。無料で公開できるか。観測できる失敗が少なくとも1つあるか。どれかひとつでも「いいえ」なら、それは作品ではなく練習問題です。
最初に作るべきで、1時間あたりの学びが最も多いのはどれか
最初の作品は、公開APIを使う天気または為替のダッシュボードです。簡単に見えますが、実際には本物のサービスが毎回行う4つのことを経験させられます。リクエストを送る、待つ、レスポンスを解析する、そして返ってきた内容が誤っていた場合を扱う、の4つです。
StrapiのAPIプロジェクトのアイデア集には、よくある候補が並んでいます。天気、映画検索、通貨換算、ポケモン図鑑、国の情報エクスプローラーなどです。特に役立つのは、NewsAPIの無料枠は開発環境に限定されているという注意書きです。つまり、その上に作ったニュース集約アプリは公開デモとして使えません。UIを作り終えてから規約を読むのではなく、プロジェクトを選ぶ前に読んでください。
最初の作品としておすすめは、通貨換算ツールか国の情報エクスプローラーです。どちらも制限が緩いか公開されておらず、キーの管理で苦労することも少なく、レスポンスの形式も安定しています。天気も作れますが、APIキーとCORSの設定だけで午後が終わってしまい、面白いコードを書く前に疲れてしまいます。
最初の版で作るべきものは次のとおりです。
1ページ、1つの入力欄、1回のAPI呼び出し、1つの表示結果
外部への呼び出しに3秒のタイムアウトを設定し、遅い上流サービスでページが固まらないようにする
呼び出しが失敗したときは、真っ白な画面ではなく分かりやすいエラー表示を出す
レスポンスを60秒間キャッシュし、再読み込みのたびに無料枠を消費しないようにする
最後の項目が、この章の教訓です。タイムアウトとキャッシュは、あなたが初めて下す信頼性の判断です。しかも、ユーザーもおらず影響もない作品の中で練習できます。
自分でAPIを持つ段階に進んだら何を作るべきか
2つ目の作品では方向を逆にします。他人のAPIを使うのではなく、自分のAPIを公開します。ブックマークサービスがちょうどよい大きさです。作成、一覧、削除、タグ付けの4つのエンドポイントと、テーブルがひとつあれば、午後ひとつで完成します。
TypeScriptかGoで書いてください。どちらも境界部分の型を明示させるため、初心者のバグが最も起きやすい場所を早い段階で意識できます。チュートリアルの多くが省く、ヘルスチェックのエンドポイントも加えてください。
// GET /healthz: データベースが応答した場合のみ200を返す
app.get("/healthz", async (_req, res) => {
try {
await db.query("select 1");
res.status(200).json({ status: "ok" });
} catch {
res.status(503).json({ status: "degraded" });
}
});このわずか10行で、プロセスが起動していることと、サービスが正しく動いていることの違いを学べます。ホスティング基盤はこのルートを定期的に確認し、失敗したらあなたのサービスを再起動できます。入門の1週目にこれを教える人は少ないですが、本来は教えるべき内容です。
次に公開します。Gitリポジトリからビルドできる無料枠のホストなら、どれでも構いません。データベースのURLはリポジトリに書かず、環境変数に入れてください。ダミーの値を入れた.env.exampleをコミットしておきましょう。本物のシークレットを一度でも公開リポジトリに入れてしまうと、二度と同じミスはしなくなりますが、その代償は大きいものです。捨ててよいデータベースで、今のうちに学んでおくほうが安全です。
マイクロサービスへの分割、メッセージキュー、Kubernetesのマニフェストは省いてください。サービスはひとつです。ひとつのサービスとして扱いましょう。
AIの機能を、おもちゃで終わらせずに加えるには
小さく作れば十分です。2025年のStack Overflow開発者調査では、回答者の84%が開発プロセスでAIツールを使っている、または使う予定があり、プロの開発者の51%が毎日使っていると報告されています。もはや雇用側は、LLMのAPIを一度でも呼んだことがある人を期待しています。問題は、それを責任を持って行ったかどうかです。
責任ある初心者向けのAI作品には3つの特徴があります。モデル呼び出しに厳しいタイムアウトを設定すること。モデルが停止または遅延したときに動くフォールバックを用意すること。そして呼び出しごとのレイテンシを記録し、p95を確認できるようにすることです。ブックマークサービスの要約機能はよい題材です。URLを貼ると2文の要約が返り、失敗したらページのタイトルを表示します。
コードの生成にアシスタントを使うなら、その出力を見知らぬ人からのプルリクエストとして扱ってください。読み、動かし、壊してみてください。GitHub CopilotやReplitのエージェントは足場作りに便利ですが、信頼性はあなたのレビューの質と同じだけです。同じ調査では、AIの出力の正確性を信頼すると答えたのは29%にとどまりました。この数字は、自分のレビュー習慣を考える際の妥当な出発点になります。
意図的にプロジェクトを壊すと何が分かるのか
これはどのリストにも載らないアイデアですが、初心者すべてに勧めたい内容です。公開したブックマークサービスで、3つの障害を起こしてください。データベース接続を切る。外部APIの呼び出しで500エラーを返させる。通常の10倍のリクエストボディを送る。
それぞれの障害は、ひとつの問いを教えてくれます。利用者には何が見えているのか、そして自分はどうやってそれを知るのか。後半の答えが、オブザーバビリティです。始めるのにほとんど道具は要りません。リクエストごとに、ステータスコードと処理時間（ミリ秒）を含むJSONを1行ずつ出力してください。それだけで「過去1時間に失敗したリクエストはいくつか」を、1行のフィルターで答えられます。
数日分のログがたまったら、グラフにしてみてください。Grafanaには無料枠があり、趣味のサービスには十分です。p95のレイテンシとエラー率を1つのパネルに表示するだけで、SLOについて1か月本を読むより多くを学べます。たとえば「リクエストの99%を500ms以内に処理する」という目標を決め、先週それを達成できていたかを確認してください。それがSLOです。難しいものではありませんが、ページャーで起こされた経験がない人の多くは、これを実践しません。
初心者でもフィーチャーフラグを使えるのか
使えます。そして、最も安上がりで実務的な習慣のひとつです。フィーチャーフラグとは、値をコードではなく設定から取得するif文のことです。AIの要約機能をこのフラグで囲み、オフの状態でリリースしてください。自分だけオンにし、次に全員に公開し、モデルプロバイダーに障害が起きたらオフに戻します。
これにプラットフォームは必要ありません。環境変数もフラグですし、JSONファイルも、より影響範囲の大きいフラグです。手作りの仕組みの限界に達したら、LaunchDarklyやStatsigのようなマネージドサービスを検討できます。そのときには、なぜ必要なのかを自分で説明できるはずです。
大切なのは道具より習慣です。「デプロイ」と「リリース」を分けて考えれば、問題のある変更は真夜中のリバートではなく、設定の切り替えで済みます。それでも、本番のチームの多くがこれを正しく扱えていません。200行のプロジェクトで、先に正しく身につけておけます。
最後まで完走できる7日間の計画
新しく学ぶ人に渡すとしたら、次のような順序を勧めます。各日に明確な区切りがあります。
1日目: 通貨または国の情報ダッシュボードを作る。ローカルのみ。API呼び出しを1回、表示を1回。
2日目: タイムアウト、エラー表示、60秒のキャッシュを追加する。公開する。
3日目: ブックマークAPIを始める。エンドポイントは4つ、テーブルは1つ、正常系のテストを書く。
4日目: ヘルスチェックを追加し、シークレットを環境変数へ移す。再び公開する。
5日目: AIの要約をフラグの背後に置き、タイムアウトとフォールバックを付ける。
6日目: 構造化したリクエストログを追加する。3つの方法でサービスを壊し、何が見えたかを書き留める。
7日目: READMEを書く。障害ごとに1段落ずつ、何を変えたかを書く。URLをひとりに送る。
足りないものにも注目してください。毎日新しいフレームワークに手を出すことはしません。ひとつのスタックを選び、そこにとどまりましょう。ひとつの言語を深く学ぶほうが、5つを浅くかじるより優れています。上の習慣は、どのスタックにも持ち越せます。
ToDoアプリはまだ作る価値があるか、そして何を省くべきか
ToDoアプリは、ほとんどの場合もう作る必要はありません。どのプログラミング作品のリストにも載っていますし、採用担当者はすでに何百個も見ています。ToDoアプリが間違いだというわけではありません。ただ、他との差がつきにくいのです。CRUDの部分は、ブックマークサービスのほうがよく学べます。
それでも作るなら、制約を変えてください。実際の認証を備えた複数ユーザー対応にする。オフラインで動き、後で同期する。2つのタブで同じ項目を編集しても壊れないようにする。学びがあるのは、こうした制約の部分です。リスト自体ではありません。
同じ考え方は、電卓、乱数生成、デジタル時計にも当てはまります。新しい言語を覚えた最初の週末には良い練習になります。しかしポートフォリオにはなりませんし、ソフトウェアを公開する経験にはなりません。
逆に省くべきものは、公開できないものです。名前を一括変更するローカル専用のPythonスクリプトは、便利なユーティリティではあっても、ポートフォリオとしては弱い作品です。デモを動かすのに有料のAPIキーが必要なプロジェクトも省いてください。「フルスタックのSNS」も避けましょう。ログイン画面に6週間を費やして、ソフトウェアを動かす経験がほとんど残りません。
同じチュートリアルを2回やった場合は、続編も避けてください。3つ目の作品は、誰も答えを教えてくれないものにすべきです。その居心地の悪さこそが、学びのポイントです。
価値があるのは、URLがあり、エンドポイントがあり、失敗するポイントがあり、何を間違えたかをREADMEで認めているものです。そうした作品は、洗練されたクローンよりもあなたについて多くを伝えます。
そこで最後に、ひとつ問いを持ち帰ってください。最初のプロジェクトが見知らぬ人の前で壊れたとき、相手が気づくより先に、あなたは気づけるでしょうか。