個人開発者 · 台中
加えて、今も稼働している15件のサイトとサービス。
Feng Chia University（逢甲大学）光電工学科の3年生で、情報系の出身ではありません。以下は、実際に完成させて引き渡したものです——自分で終了させたプロダクト1つを含めて。
5本のアプリは自分の会社のアカウントGomiigo Games（法人名：Tuthome Co., Ltd.）名義で公開しています。いずれも設計から公開まで、すべて自分で手がけました。以下のサイトとサービスはすべて、自分で管理している1台のLinuxサーバーで動いています。
政府機関と報道機関の約10のソースを、大切な人の近くで実際に起きたときだけ鳴る災害アラートに変えます。
多くのアラートアプリが失敗するのは、事象を見逃すからではありません。鳴りすぎて、通知を切られるからです。このアプリは受け取った事象を重複排除し、3段階の信頼度で評価したうえで、ユーザーが設定した「生活圏」——半径と時間帯を持つ家族と場所——に事象が重なったときだけ通知します。自宅の住所はAES-GCMで暗号化して保存し、ホーム画面のウィジェットはApp Groupのスナップショットのみを読み、位置情報には触れません。
今日を3×3のグリッドに並べ、ひとつ終えるごとにマスがひとつ灯る。ゼロから審査提出まで8日。
標準のListやTabViewではなく、自作のUIコンポーネントシステムの上に構築。7言語・871件の文字列は手作業で写すのではなく3本のスクリプトで組み立て、ストアの掲載情報、審査情報、各言語のスクリーンショット84枚はすべてApp Store Connect API経由でアップロードしています。
自作の無料ブラウザゲームサイト。載っているゲームも自分で作ったものです。
プラットフォーム自体はNext.jsですが、時間をかけたのはゲームの方です。Godot、Phaser 3、React、素のCanvasという4つの異なる技術ルートを採ったのは、同じ種類のゲームプレイが各エンジンで実際にどれだけのコストを要するのかを知りたかったからです。そのうち1本はGodotからPhaserへ丸ごと移植し、その移植の過程は再利用できる手順としてまとめ、その後もう一度使っています。
業務委託のエンジニアとして、稼働中のNext.js + Supabaseプラットフォームの中で作業し、セキュリティ欠陥を2件見つけて修正しました。
ゼロからの新規開発ではなく、他人が書いたコードベースの中で、すでに実際のユーザーがいる状態での作業でした。2件の欠陥は、複数ロールの権限モデルにおける権限昇格の経路と、テナントをまたいだデータ露出です。変更はすべて、row-level securityポリシーで管理されたPostgresスキーマに対し、レビュー済みのpull requestとして納品しました。クライアント名は取り決めにより公開していません。
自分のために書いた作業ルール一式。仕事をどう振り分け、どう検証し、失敗のひとつひとつをどうルールに変えるか。
中核となるルールは一行です。作った本人は検証しない。何かが完成したら、その経緯を一切知らない新しいセッションを開き、返せる答えは3つに限定します——合格、証拠付きの不合格、「検証不能」。その横には、10か月間に起きた問題を記録した34件のログがあり、それぞれが以後の仕事に適用できるルールとして書き直されています。
オーストラリアの引越し会社のCRMに、3つの自動化を組み込みました。AIによる作業員のスケジューリング、メールからの受注抽出、そして配送ルートの最適化です。
クライアントにはすでにBase44で作られた低コードのCRMがあり、私の仕事はそれを自走させることでした。AIスケジューリングは空き状況と所在地から作業員を割り当て、メール解析は届いた問い合わせを構造化された受注データに変換し、ルート最適化はその日の配送をいちばん安く回れる順路を割り出します。AIの呼び出しはサーバーレス関数を経由し、使うモデルはコード内で明示しています。納品して案件は終了し、3回に分けた支払いもすべて完了しています。
いずれも現在も稼働中で、直接開いて確認できます。「要ログイン」と記したものはアカウント機能を持つため、プロダクト本体ではなくログイン画面が表示されます。
アイデアをキャンバスに描き、ノード間のつながりに沿ってAIに展開させます。
小規模事業者向けの注文システム。8店舗にDMで提案し、事前に決めておいた判定日の結果は、成約ゼロ。自分で終了させました。
構想は「1店舗につき設定ファイル1つ」。新しい店向けに1時間で装いを変えられる、ホワイトラベルの注文ページでした。始める前に合否の基準と撤退条件を書き、決めておいた日に決着をつけました。3つの条件はすべて不合格。それでもこのページに残しているのは、どの成功例よりも、私がどう判断するかを物語っているからです。何をもって失敗とするかを先に決め、その時が来たら実際にそう認める。
自分の受託開発スタジオのサイト。いまのツールはそのままに、ワークフローを自動化する。
フォームに入力する代わりに、チャットでカレンダーをつけます。
Threadsの投稿を分類・フィルタリングし、読みたいものだけを通します。
データが自分のブラウザ内にとどまり、どこにもアップロードされない家計簿。
よく使う計算とグラフを1か所にまとめた数学ツールボックス。
AIの学習パートナー。質問1つに対し、5〜6段階の分析を連ねてから答えます。
個人用のAIアシスタントプラットフォーム。回答は生成されるそばからストリーミングで届きます。
AIアシスタントをLINEとTelegramに載せます。1つのワークスペースで複数のペルソナとその連絡先を管理できます。
問題を撮影または入力すると、手順を追った解説が返ってきます。AI層には6段階のフォールバックがあります。
ブラウザ標準のWeb Crypto APIを使い、鍵を暗号化してブラウザ内に保存します。
その日やったことを1日1行。自宅のNASで動いています。
自分の課題を解決するために書いたものです。多くは公開インターフェースを持ちません。
ここに載せた中でいちばん古いプロジェクト。LINE botの裏に、スケジューリング、タスクキュー、データモデルまでゼロから組んだフルバックエンドがあります。
私にとって最初の本格的なバックエンドでした。表にはLINE botがあり、その裏でFastAPIが18のデータモデルにまたがる44のエンドポイントを提供し、Celeryが定期ジョブと非同期ジョブを回し、MySQLが保存、Redisがキャッシュを担っています。すべてDockerで動かし、隣には自分でホストしているGiteaがあります。AIはどこにも使っていません。当時はまだ、そこに手をつけていませんでした。
自分の課題を解決するために作ったもの。求人情報を収集し、段階的なAIフィルターで選別し、応募したものを追跡します。
AIが自分のスキルライブラリを直接読めるようにする、Model Context Protocolサーバー。
Model Context Protocolは、AIが外部のデータを直接読めるようにする仕組みです。自分のスキルライブラリをその都度切り貼りして渡す代わりに、AIの側から直接問い合わせられるよう、Next.jsでMCPサーバーを書きました。下にはDrizzleとSQLite、リポジトリのデータ用にGitHub APIを使っています。
ページ上の気が散る部分をマスクするChrome拡張機能。
Manifest V3のChrome拡張機能です。やることはひとつだけ。ページの中で、自分がつい見てしまう部分——サイドバーのおすすめ、下に並ぶ関連動画、SNSのフィード——をマスクします。ルールはブラウザの中に置くだけで、アカウントも不要、何もアップロードしません。
Visionフレームワークの上に構築した撮影アシスタント。8言語対応で、現在TestFlightで配信中。
AppleのVisionフレームワークでフレームをリアルタイムに解析し、カメラはAVFoundationで制御しています。そのため、シャッターを押す前に構図のどこがおかしいかを教えてくれます。8言語対応、114件のcommit、現在はTestFlightで配信中で、App Storeにはまだ提出していません。
構想からApp Store審査提出まで3日で仕上げた小さなゲームアプリ。
狙いは複雑さではありません。ひとつのアイデアを審査提出まで押し切るのに、自分はどれだけかかるのかを知りたかったのです。結果は3日。アートワーク、IAPの設定、ストア用素材まで含めてです。
在庫管理のプロトタイプ。ここに載せた中で唯一Vueで書いたものです。
在庫管理のプロトタイプです。商品、在庫、入庫、出庫、顧客をカバーする9つのテーブルで構成しています。ここに載せた中で唯一Vueで書いたもので、VueとReactが実際の作業でどこが違うのかを知るために、あえて選びました。
多くの人はAIを回答マシンとして使っています。聞いて、受け取って、次へ進む。私の成果を変えた習慣は、「作る」と「確かめる」を分けることでした。何かを終えたばかりのセッションに、その評価をさせることはありません。書いたばかりのセッションは自分の成果を擁護します。一度も見たことのないセッションはそうしません。
以前は、複数のAIエージェントに仕事を振り分けることがコストを押し上げる原因だと確信していて、すべてを一つの会話の中で済ませていました。そこで自分のセッション170件を実際に測ってみると、メインの会話がコストの約88%を占め、振り分けたエージェントすべてを合わせても約12%でした。因果関係を逆に捉えていたのです。記憶に残ったのは数字そのものではありません。確信を持った意見を何か月も抱えたまま一度も確かめておらず、確かめるのにかかったのは1時間ほどだった、ということです。
私の仕事の大半はAIの支援を受けていますし、それを隠すつもりはありません。ただし分担は明確です。量はAIが担い、判断は自分が持つ。何を作るか、何をもって完了とするか、どこで妥協しないか。これらは委ねません。
華柏翰（Po-Han Hua）です。台中のFeng Chia University（逢甲大学）で光電工学を専攻する3年生で、2028年春に卒業予定です。
情報系の出身ではありません。あってほしいと思うものを実際に作ることで、ソフトウェアの作り方を学びました。情報系以外の学生でも、この方法で本物を作れる人は多いはずです。光学実験で隣に座っている同級生にもできる。ただ、そう言われたことがないだけです。
受託案件や協業の相談を歓迎します。いま作っているものの話を聞かせてもらうだけでも構いません。