表向きはハッカソン勝率100%。裏側は「動くゴミ」。DBはJSON、APIキー漏洩……専門1年生の泥臭すぎる生存記録
はじめに：専門1年生、戦場での記録
はじめまして、専門学校1年生の わかと です。
2025年、私はエンジニアとしての経験を積むため、数々のハッカソンやコンテストに挑戦しました。
結果として、以下の成果を残すことができました。
- 技育CAMP： 優秀賞 2回 /努力賞 1回
- うめきた tech base： 最優秀賞
- 技育博： 倍率3倍を通過し展示
- ヒーローズ・リーグ： 4作品応募（うち1作品決勝進出）
- ハッカソン勝率： 100%
これだけを見ると「さぞ高度で美しいコードを書いているのだろう」と思われるかもしれません。
しかし、実態は真逆です。私がハッカソンや開発の現場で量産したのは、「ゴミリーダブルコード」（ゴミのように汚いが、動くコード）でした。
この記事は、技術を学び始めて1年未満の私が、なぜ「汚いコード」を量産してまで完成を急いだのか。そして、その**「泥臭いピボット（という名のやらかし）」**でどう乗り切ったのかという、振り返りと反省の記録です。
1. ハッカソンで勝つための「推論」と、私なりの「勝利」の定義
本題に入る前に、一つだけ。
そもそも私は、ハッカソンにおいて**「賞を獲る＝勝者」だとはあまり思っていません。**
賞というのは、あくまで審査員という他者からの「一つの評価」に過ぎないからです。
私にとっての本当の「勝利」とは、**「自分の中で目標を一つ設定し、それをやり遂げること」**です。自分が決めた壁を越えられたなら、賞の有無に関わらず、その時点で自分の中では「優勝」だと思っています。
その上で、もし「賞（他者からの評価）を獲得する」という目標を設定したならば、どう動くべきか。ハッカソンに参加し始めた当初、私はある仮説を立てました。
「審査員が見ているのは、GitHubのコミットログではない。目の前のデモ画面だ」
ハッカソンの評価軸を分析すると、以下のようになります。
- オーディエンス（技育CAMPなど）： 「アイデアの面白さ」「インパクト」「プレゼン」
- 企業（スポンサー賞など）： 「社会的意義」「新しさ」「拡張性」
どちらが相手でも、共通している絶対条件は**「プレゼン中に、アイデア通りの挙動がバグなく動くこと」**です。
私はここで、ひとつの冷徹な方程式を導き出しました。
ここに「コードの綺麗さ（保守性）」という変数は、短期決戦においては（極論ですが）ゼロでも構わない。
そう割り切った瞬間、私の**「技術選定」と「コーディング戦略」**は劇的に変わりました。
章2. 個人開発：技育博への挑戦 (Weather App)
〜「モダンな技術」の皮を被ったAIの継ぎ接ぎ〜
まずは、じっくり時間をかけられるはずの個人開発、**技育博（展示通過作品）**のエピソードからです。
ここでは「モダンで堅牢な設計」を目指し、Next.js (App Router), TypeScript, Tailwind CSS を採用しました。
しかし、実態はAIにコーディングを丸投げした「爆速開発」でした。
Case 1: 個人開発でも「神コンポーネント」とAIの痕跡
本来なら Header, Footer, MainContent... とコンポーネントを綺麗に分割するのが定石です。
しかし、私はAI（生成AI）にコーディングを任せることを選びました。その結果、1つのファイルが平気で 320行 を超えました。
注目していただきたいのは、**深い深いネスト（通称：波動拳インデント）**だけではありません。
310行目付近のコメントにご注目ください。
// --- ★props変更 ...
これはAIに修正を依頼した時の出力コメントがそのまま残っています。
「AIが書いたコードを、人間が検品せずにコピペして動かす」。
個人開発であっても「綺麗さ」より「完成（審査通過）」を最優先した、私の**「生存の証」**です。
章3. ハッカソン：GitHub Planet (優秀賞)
〜混沌（カオス）を抱きしめてゴールする〜
続いては、ハッカソンで優秀賞を獲得した GitHub Planet での記録です。
ここでは「Supabaseを捨ててGitHub APIへピボットする」という大きな決断をしましたが、コードの中身もまた、壮絶な戦場でした。
Case 2: 継ぎ足しの秘伝タレ化したCSS
ここではTailwind CSSなどの便利なフレームワークは使いませんでした。
「普通にCSSを書く」。ただそれだけを愚直に繰り返した結果、1つのCSSファイルが 550行 を超えました。
クラス設計などありません。「動けばいい」「見た目が整えばいい」。
一番下に新しいスタイルを追記し続ける、完全なる技術的負債の塊です。
しかし、この手書きの600行が、審査員の心を動かすアニメーションを生み出したのです。
Case 3: デプロイ優先の「全部入りindex.html」と「聖域化」された友人コード
ハッカソンの締め切り直前、デプロイ先の Render で動かすために、私は**「大統合」**を行いました。
本来分けて作っていた「タイトル画面（welcome.html）」を、無理やりメインの index.html にコピペで結合。
JavaScriptで display: none を切り替えるだけの、疑似SPA（Single Page Anarchy） を爆誕させました。
その結果、フォルダの中には**「もう使われない welcome.html」や「welcome.js」**が削除されずにゾンビとして残留しています。
さらに恐ろしいのが、メインのロジックを担う home.js（480行） です。
DOM操作・API通信・Three.js描画・シェーダー定義（JS内に文字列で埋め込み）が全て詰まったこのファイル。
実はこれ、ハッカソンでチームを組んだ友人が書いたコードです。
本来ならリファクタリングすべきですが、中身はThree.jsの魔術的記述で満たされており、私の理解を超えていました。
下手に触って動かなくなるのが怖すぎて、私はこのファイルを**「聖域（サンクチュアリ）」**として認定。
変数名ひとつ変えることなく、そのままデプロイしました。
「動いているコードには触れるな」。
技術的負債を返済せず、そのまま抱きしめてゴールテープを切る。これもまた、ハッカソンにおける生存戦略の一つです。
Case 4: 世界公開してしまった秘密鍵（大反省）
これは本当に内緒にしておきたかったのですが、ハッカソンの興奮状態とは恐ろしいものです。
開発中、環境変数を設定するのが面倒だった私は、APIキー（Client Secret）を server.js に直接ベタ書きしました。
「後で直せばいいや」。そう思っていましたが、当然そんな時間はなく、そのままGitHubにプッシュ。
……という話を「過去の反省」として書こうと思いましたが、この記事を書いている途中で気付いて血の気が引きました。実は、さっきまで直していませんでした。
（※現在は即座にキーをRevoke（無効化）し、環境変数に移行済みです。）
ハッカソンの興奮状態とは恐ろしいもので、当時は「動けばいい」とベタ書きし、そのまま放置していました。もし悪意のあるBotに拾われていたらと思うとゾッとします。開発速度を優先するにしても、セキュリティだけは絶対に犠牲にしてはいけないと痛感した最大の教訓です。
章4. ハッカソン：きじょバト (努力賞)
〜無知を武器に変えた「ファイルシステムDB」〜
これは、まだ私がデータベース（DB）の概念を完全に理解できていなかった頃の話です。
周りのチームがMySQLやFirestoreを使っている中、私は正直に認めました。「今の自分にDB構築は荷が重い」と。
そこで採用した技術スタックは、**「生JSONファイル」**です。
Case 5: データベース？ いいえ、JSONです。
データの保存・読み出しは全てローカルのJSONファイルを fs モジュールで読み書きするだけ。
排他制御？ パフォーマンス？ 知りません。デモの数分間さえ動けばいいのです。
見てください、これが私のデータベース設計（？）です。
ORMの設定も接続プールもありません。あるのは kisorironn.json、network.json といったファイルパスの定義だけ。
これを fs.readFileSync で無理やり読み込み、メモリ上で処理して fs.writeFileSync で保存する。
この**「技術的な背伸びをしない」**戦略のおかげで、DB接続エラーに1秒も悩まされることなく実装を完了させ、努力賞をもぎ取りました。
「高尚な技術を使って完成しない」よりも、「原始的な技術で完成させる」ことの価値を知った瞬間です。
章5. ハッカソン：うめきた tech base (最優秀賞)
〜セキュリティ意識を犠牲に召喚した勝利〜
最後は、最優秀賞に輝いた うめきた tech base での出来事です。
ここでは「Gemini APIが動かずHugging Faceへ切り替える」という英断を下しましたが、その裏ではもっと恐ろしいことが起きていました。
Case 6: Gemini沈黙からのHugging Face
生成AIプロダクトの開発中、当時話題の Gemini API を採用しました。
しかし、なんとハッカソン当日にレスポンスが返ってこないトラブルが発生。「メイン機能が動かない＝死」という絶体絶命のピンチです。
ここで即座にプランBを発動。以前少しだけ触ったことのあった Hugging Face API へ接続先を切り替えました。
Node.js (Express) で書いていたおかげで、エンドポイントとリクエストボディの修正だけでピボット完了。
審査員の前でAIは見事に回答を生成し、最優秀賞に輝きました。
（余談ですが）
この緊急対応には「オチ」があります。
後日、Hugging Faceの無料枠を使い切り、APIが静かに息を引き取りました（停止しました）。
学生の私には追加で課金する予算（7ドル）がなく、現在のデモアプリはあえなく沈黙しています。
Case 7: .envごとのプッシュと謎の「〇」
さらに、.env ファイルには別の悲劇も刻まれています。
STABILITY_API_KEY=sk-AKi...
画像生成AIのAPIキーです。これもあろうことか .env ごとプッシュされ、当然のように**制限（BAN）**を食らっています。
しかも、この行の横には**「〇」という謎の文字が。
チーム開発中、友人が何かを意図して書いたようですが、「なんか〇あるし、よーわからんから放置」**した結果、無効なキーと謎の文字がセットで世界に公開されてしまっていました。（※こちらも現在はキーを無効化・削除済みです）
セキュリティ意識すらも犠牲にして開発速度を優先した（ただの不注意とも言う）猛省すべき結果です。
結論：2025年の総括
専門1年生の私にとって、2025年は「技術」という武器の使い方を学んだ1年でした。
- 時間がなければ、JSONやAPI直叩き、ゾンビファイルや聖域化したコードの放置、さらにはAPIキーの公開すらも辞さない**「ナイフ」**で戦う。
- 時間があれば、AIとモダン技術という**「重装備」**で戦う。
「技術的チャレンジ」とは、単に綺麗なコードを書くことだけではありません。
「限られたリソースの中で、目的（勝利・完成）のためにあらゆる手段を使い倒し、実行すること」。
泥臭い実装も、AIが生んだ300行のコードも、ハッカソンを勝ち抜くためのサバイバル術でした。しかし、APIキーを公開してしまったり、運用を考えないスパゲッティコードを残したりしたのは、完全に私の「未熟さ」であり失敗です。
手段を選ばず「完成させる力」はついたので、来年はこの負債を生まないための「正しい設計とセキュリティ」を身につける1年にします。
最後に：ゴミリーダブルコードの鑑賞会へようこそ
ここまで読んで「嘘だろ？」と思ったそこのあなた。
私のGitHubプロフィールには、これら全ての**「戦いの記録（ゴミリーダブルコード）」**が眠っています。
480行のスパゲッティコード、ベタ書きされたAPIキー、無限に続く if 文……。
教科書には載っていない「生存本能」が書き殴ったコードの数々を、ぜひご自身の目で鑑賞し、笑ってください。
そして、もしハッカソンで時間がなくて絶望した時は、私のコードを思い出してください。「これで勝てるんだ」と勇気が湧いてくるはずです。
Discussion