エンジニアになって半年、身近な教室を支える開発から、その活動を外へ届けるプロダクトづくりへ

前半は、教育の現場を辞めて特別支援教育を学び直しながら、塾の出席管理を0から作り、AIに任せる範囲を少しずつ広げていった1年の話でした。その1年の終わり、2026年3月に、IT企業にエンジニアとして入りました。ここからが後半です。

tatsunoritojo.com · 2026-09-20

特別支援教育を学び直すために仕事を辞めたら、1年後にエンジニアとして内定をもらっていた

エンジニアになりたい気持ちを持ったまま、教育の現場に3年いた。2025年3月に辞めて特別支援教育を学び直しながら、エンジニアと教員の2軸で就職活動をし、その1年が終わる前にIT企業から内定が出た。AIに出会い、使い倒して学習を加速した2年間を、節ごとに「そのとき手元にあったAI」と「AIへの累積課金額」の表を置きながら書いた前半。

後半はその続きです。昼は所属先で、5月に新入社員研修のサブ講師を務め、6月からは既存の古くなったシステムをリプレースする案件に、要件定義の段階から入っています。先輩のエンジニアにClaude Codeの使い方を伝える役も担うようになりました。夜と休日は、個人開発を進め続けました。塾のシステムの改善と保守、シフト管理、ポートフォリオ、後輩のサークルのサイト。身近な教室を支えるものです。

その半年の途中で、塾の代表から「テスト校が見つかった」と連絡が来ました。塾の出席管理を作り始めたころから代表と共有していた構想を、別の教室に届ける話です。

作ったのは「uni」という、フリースクールや小さな教室のための、出席と連携のクラウドです。生徒は教室に着いたら、自分のスマホか、印刷したQRカードを受付のタブレットにかざして、入室を記録します。スマホはパスキーで本人を覚えておくので、毎回ログインし直す必要はありません。続けて、3つの質問に答えます。きょうの気分はどんな天気か。きのうはよく眠れたか。きょうは何をしに来たか。その回答が日々積み重なり、先生は教室での様子と合わせて一人ひとりの調子を把握し、声をかけるきっかけにします。生徒の側は、自分の調子を確かめ、どう過ごしたいかを考える。出席の記録はその入口で、中心にあるのは、状態の把握と、本人・家庭・先生同士の対話です。

その構想を別の教室で試せる機会が来て、私は引き受けました。そこから8週間で、15万行規模（物理行の実測で約14.6万行）のSaaSを本番に載せました。プロトタイプではなく、運用できるものです。

前半と同じく、各節の終わりに、そのとき手元にあったAIと、AIへの課金の累積額を表で置きます。累積は約12万円から約29万円になります。この記事の数字は、金額が請求日ごとの為替で換算した推計、コミットとPRが記録の集計、操作時間がログからの推計（実機確認や打ち合わせを含みません）です。

図2. AIに払った金額の累積（円）と、月ごとのコミット数。前半の図1と同じ軸を2026年9月まで延ばした。金額は請求日ごとの為替で換算した推計、コミット数は手元の全リポジトリの実測

1. エンジニアとしての最初の半年 — 研修の講師と要件定義

2026年3月、IT企業にソフトウェアエンジニアとして入りました。所属先では、案件ごとにアサインされて働いています。

5月には、新入社員研修のサブ講師を務めました。教育の現場で人に教えてきた経験を、今度はエンジニアの育成の場で使うことになりました。

6月からは、既存の古くなったシステムをリプレースする案件に、要件定義の段階から関わっています。現在は基本設計まで進み、Claudeを使った設計書の自動化や、質の高いドキュメントを作るためのプロジェクト設定の調整を担当しています。

チームでは、Claudeをどう業務に入れるかがまだ定まっていませんでした。画面設計書の作成が回ってきたとき、私は設計書を直接書く代わりに、モックのコードから設計書を起こす道具を作ることにしました。それを使うことを提案すると、PLが興味を持ってくれて、先輩のエンジニアと一緒に作り込むことになりました。

一緒に作っているうちに、その先輩もやり方をつかんでいきました。「想定した出力になるようにツールを調整するのも面白い」と話されるくらい、すぐにClaudeに慣れられていました。ほかの設計書も、同じようにツールを作って調整する形で、自動で作られるようになっていきました。

夜と休日は、個人開発を止めませんでした。4月に、大学時代の後輩がいる3Dプリンターサークルの公式サイト、Python認定試験向けのクイズ、予定を知らせるLINE Bot。この月のコミットは196件でした。同じ4月から、AI活用研修の動画を作る仕事を受託しました。台本、モック、収録、納品まで一人でやっています。

6月5日、開発環境をWindowsからMacに移しました。この移行にもClaude Codeを使いました。進行状況を共有するためのリポジトリをGitHubに作り、移行前のWindows機のClaude Codeと、Mac機のClaude Codeが、そこで進捗をやりとりする。OSが変わるのでファイルパスの調整も必要でしたが、それも任せました。移行はスムーズに進み、その日から、作業の続きを正確に進められました。

7月には、シフト管理のシフリーに、カレンダー中心のシフト構築、日と週の単位での確定、勤務時間の集計、欠員の補充、複数の組織への並行所属を本番導入しました。7月14日には、ポートフォリオのケーススタディを作り直しました。

AIとの関係で言うと、5月12日時点の集計で、コミット792件のうちClaudeと共同で作ったものが655件、82.7%でした。作るのはAI、確認と判断は私、という前半の終わりの配分が、そのまま続いていました。

2. 本番での失敗 — 検知できても止められなかった障害

7月、運用しているプロダクトの一つで、認証の入口が止まる障害を起こしました。データベースの変更が本番に届かないまま、新しいコードがデプロイされたためです。足したのは1列だけでした。それでも、その1列が無いだけで、認証に関わる処理が丸ごと落ちます。

同じ型の障害は、それまでにも起きていました。調べると、検知は毎回できていました。スキーマの食い違いを見つけて、ログに警告を出す仕組みは動いていた。無かったのは、止める仕組みです。5月に警告を出すところまでを入れ、遮断は「しばらく観測してから有効にする」としたまま、2か月が過ぎていました。

復旧後、自動での適用に頼るのをやめました。データベースの変更は制御した1回の手順で当て、本番のデータベースを実際に確かめてから、本番を切り替える。マージしただけでは本番が変わらないようにもしました。適用の順序を人の注意に任せないための設計は、ADRにまとめてあります。遮断とCIでの適用は、設計を決めたところで、実装はこれからです。

複数のAIセッションを同じリポジトリで並行して動かしていると、あるセッションのブランチ切り替えが、別のセッションの未コミットの成果を巻き込みます。7月4日、28ファイルでそれが起きました。作業ツリーをセッションごとに分け、自分が作っていない変更がある状態での切り替えを、フックで物理的に止めました。

どちらも、開発の現場ではよく知られた種類の失敗です。私はそれを自分の本番で経験し、そのたびに、注意ではなく仕組みで止める形に変えてきました。

この時期に変えたことを、起きたことと対応させて並べます。

規則を文章で書くだけでは、足りませんでした。だから、止める側を仕組みにしました。ここで置いた仕組みは、このあとのuniの開発で、そのまま土台になります。

障害が起きたときだけではありません。運用しているアプリケーションは、セキュリティの面を定期的に見直しています。6月には、塾のシステムのアクセス制御を本人識別の方式に作り直し、個人情報を持たない作りに変えました。あわせて監査の手順を整え、公開リポジトリへ秘密を押し込めないように、push時のフックも置きました。

7月8日からは、判断の記録をObsidianのVaultに集め、Claude Codeが自分の失敗を規則に変えるループを回し始めました。6月末には、Grokのサブスクリプションにも課金を始めました。

3. こども家庭庁の事例掲載と、じっくりやるつもりだったSaaS

7月24日、前半で書いた「こどもの進路案内所」が、こども家庭庁の「こどもまんなかアクション」の事例ページに掲載されました。中学校卒業後の多様な進路を可視化し、自分に合った道を選べるようサポートする診断サイト、という紹介です。もともとは、塾の代表の構想でした。私はその構想を受け取り、内部でレビューをもらって出てきた意見をまとめながら、実装は一人で進めました。その取り組みが、公的な場で紹介されました。

進路案内所でやったのは、構想を形にして、教室の外へ届けることでした。

同じころ、同じ向きの話をもう一つ進めていました。塾の出席管理を、汎用のSaaSにする構想です。こちらは、塾のアプリを作り始めた当初からあり、代表とも共有していました。3月にリポジトリを作り、当初はDjangoで考えていました。4月には、面談のメモと、プロダクトの仕様の確定版を文書にしています。その後も空いた時間にChatGPTで壁打ちを続け、7月18日にはUIのモックを見ながら指摘と決定を記録しました。7月24日には代表に同席してもらい、塾で動いている現行の機能86件を、新しいSaaSに要るもの、保留、要らないものに仕分けています。要ると判定したのは57件でした。仕様を固めてから、ウォーターフォール的に、時間をかけて作るつもりでした。

写真3. こども家庭庁の事例ページ

www.cfa.go.jp

居場所づくり・こども食堂｜こども家庭庁

こども家庭庁は、こどもがまんなかの社会を実現するためにこどもの視点に立って意見を聴き、こどもにとっていちばんの利益を考え、こどもと家庭の、福祉や健康の向上を支援し、こどもの権利を守るためのこども政策に強力なリーダーシップをもって取り組みます。

4. 「テスト校が見つかった」に即答した日

7月25日、塾の代表から「テスト校が見つかった」と連絡が来ました。協力してくれるのは、通信制高校のサポート校です。代表は、共有していたこの構想を、春ごろに周りの人にも話していたそうです。それを覚えていた人が、時間を置いて、新しい教室を開くときに入れてみたいと、代表に声をかけてくれました。

即答でOKしました。ただ、その場でコードを書き始めたわけではありません。手元には、4月の仕様、7月のモックの検討、前日の機能の仕分け、そして私が持ち込んだアーキテクチャの構成案がありました。もう一つ、土台になったものがあります。塾のシステムのリポジトリは、定期的に構成を整理して、機能の一覧などの文書を保ってきました。その文書を骨格に使えたので、機能一覧をはじめとする要件定義を、すぐに確定させることができました。7月25日には、これらを設計の文書として揃えました。前日に要ると判定した57件を、新しい機能の一覧へ1件ずつ対応させた要件定義の骨子。認証の方式、マルチテナントの境界、データの置き場所を整理したアーキテクチャの設計。

そこから、具体的に使うサービスを決めていきました。大きな方向は決まっていました。塾のデスクトップアプリを約1年運用して出ていた課題を解決する形で、すでに頭の中にありました。ちょうどCloudflareのD1が注目されていた時期で、運用の費用をかなり安く設計できる見込みも持っていました。午後は、その見込みを具体化する作業です。Cloudflareの制約と月々のコストを調べ、技術レビューで出た指摘を材料に、骨子を直していきました。そのうえで、Cloudflare Workers + D1 + TypeScriptに決め、Django案を捨て、名前を「uni」にしました。主な対象を参加者100人未満の小さな教室にすること、初期のインフラ費を月1,000円未満に収めることも、この日に私が決めたものです。

ロゴは、移動の時間などにChatGPTと構想を壁打ちし、いくつかの案の中から決めました。

図3. uniのロゴ

並行して、受付端末での入退室の処理が成立するかを、小さな実験で確かめました。その実験を経て、夜の10時にコードを開発用の場所へ移しました。翌日には、これを試作ではなく、本番相当の開発として扱うと決めています。

それまでの経験を総動員しました。DB設計はシフリーから、フロントエンドのTypeScriptは進路案内所から、エージェントの動かし方とGitHubの使い方は、この1年の経験から。

初日から、AIを分業させました。Grokが実装、Codexがレビューゲート、Claudeが統合と判断。Grokのターミナル向けエージェントは、early betaとして公開されていた時期でした。この分業は、8週間の間に3回変わりました。

予定は、8月20日と21日のオープンスクールでお披露目、9月に本番開始。開発に使える期間は1か月でした。

5. 8週間 — エージェントの自走と、失敗を数日で制度に変える

8週間のあいだ、開発はgoal/loop型の自走で進めました。ゴールを渡して、エージェントが自分で計画し、実装し、検証し、次に進む。私は夜と休日にログを読み、裁定し、方向を直しました。

自走の前提にしたのは、役割を分けることと、決定を残すことです。仕様と検証はClaude、敵対的なレビューはCodex、定型の実装はGrok、決定は私。重要な設計の変更では、Codexの敵対的なレビューを判断の材料にしました。私が決めたことは、1件ずつ番号を振って決定の記録に残しています。9月の時点で105件です。動いていることは、仕様の根拠にしない。これも決まりにしました。たとえば3つの質問の画面は、動いていた最初の実装がモックと設計の決定に合っていなかったので、破棄して作り直しています。テーブルの関係図とAPIの一覧は、コードから自動で生成する形にしました。

うまくいかなかったことも、すぐに表に出ました。着手前のゲートを増やしすぎると開発は止まり、落ちようのない検査を並べれば、全件合格という報告だけが残ります。裁定待ちは65件まで溜まり、実装エージェントは「PoC」という自己申告を理由に、本番に必要な要件を外へ置こうとしました。どれも、数日のうちに仕組みへ変えています。これらは別の記事に書いたので、ここでは繰り返しません。

tatsunoritojo.com · 2026-08-09

アプリケーションをループエンジニアリングで開発したらドキュメントの陳腐化が加速した

goal/loop を意識した自走では、記憶をマークダウンに外出しする必要が出る。文書が増え、読み切る前に次の判断材料になる構造が生まれ、陳腐化した前提が方針として流通した。検証では捕まらないその穴を、決定登録簿と逆参照（裁定層）で塞いだ記録。

私が自分の手に残したのは、価値判断です。三つ挙げます。

一つ目は、利用者が誰か。要件文書とエージェントの分析が「子ども」という語から、現実より低年齢の利用者像を作っていました。画面の文言が幼くなっていた。使うのは通信制高校のサポート校に通う中高生です。利用者像を中高生に確定して、文言を直させました。同じ調整を二度言わせないよう、決定として記録させました。

二つ目は、どの端末で何を開いてよいか。受付端末から管理画面を開ける構造になっていました。玄関の共用タブレットで、生徒の個人情報を開ける運用になります。受付端末と管理端末を完全に分けました。

三つ目は、納期を完成の定義に入れるか。7月29日に8月20日のオープンスクールを「最悪のデッドライン」と言いました。8月2日には、固定の納期を製品の完成の定義から外しました。日付に合わせて削るより、新しい教室がテナントとして参加し、来所の記録と状態の把握を運用できることを完成とする。そう決めました。

検証は、テストとCIに寄せました。自走中はスライスごとの実機確認を挟まず、typecheckとテストとCIで検証する。テスト環境では随時確認していましたが、それでも、typecheckもsmokeも全部緑のまま、管理ポータルのログアウトが無反応だったことがあります。許容したリスクの実例です。

Codexの枠が切れた8月の初めは、Grokがゲートも兼ねました。Grokは速くて安い一方で、事実と違う報告をすることがあり、当初は苦労しました。ハーネスを厳しく引き締めて対処しました。

7月24日から8月23日までの31日間で、私の操作時間は163時間（ログからの推計）、uniのコミットは981件、PRは149本でした。手元の全リポジトリで数えると、8月の暦月で835件です（9月18日時点の集計）。この8週間に使っていたモデルは、Fable 5とOpus 5が中心で、9月に入ってFable 5.1が加わりました。

写真4. uniの受付画面と管理画面（デモ用のダミーデータ）

6. デモと本番開始

8月21日、オープンスクールでのデモは無事に終わりました。作ったものが、開発者の手元を離れて、実際の学校の説明の中で使われた日でした。協力してくれた人が2日目にuniをプレゼンし、その学校の理事長から、テスト校を増やしてもいいという打診がありました。その話は、まだ進んでいません。

8月28日、本番環境に反映しました。9月1日、テスト校で運用が始まりました。これまでと違ったのは、クライアントが外部だったことです。障害は許されず、進捗は定期的に報告しました。

7. 運用開始から3日後 — スマホでブラウザを開けない生徒と、出席カード

9月4日、運用開始から3日後に、テスト校から連絡がありました。保護者の設定でスマホのブラウザを開けない生徒がいる。パスキーの設定そのものができない生徒もいる。端末を持たない生徒もいる。参加者はスマホで出席を登録する設計でしたが、その前提が崩れました。

塾の出席管理では、2025年から今も、印刷したQRカードを受付で読む方式を使っています。uniでは、カードよりも、スマホでの認証を第一の選択肢にしていました。この先、生徒がスマホの認証を使って、自分のデータを見られる機能も作りたいと考えていたからです。それなら最初から、物理のカードではなくデジタルに寄せておいたほうが、使える人の幅が広がる。そういう仮説でした。

現実は、その逆でした。先の拡張を見込んでデジタルで解こうとして、いま目の前にいる利用者の想定を見誤っていました。

当日、登録に失敗した生徒の出席は、手動の入力で記録してもらえました。受付の端末には、うまく読み取れないときの保険として、手で出席を入力する方法を前から入れてありました。この機能のことは、説明していませんでした。それでも利用者は、自分でそこにたどり着いて使っていました。それは、受付を止めないための導線が機能していた証拠になりました。

手動の入力では、本人確認用の目印として、動物のマークを使います。利用者の登録には、入り口を2つ用意しています。管理者が手で設定する方法と、申請フォームを配って、そこから登録してもらう方法です。どちらでも、登録のときに、自分の目印になる動物のマークを選びます。受付の端末では、そのマークで本人を確かめます。

連絡を受けて、10分ほどで返信しました。受付のタブレットのカメラで、印刷したQRコードのカードを読む画面を実装すること。機器を買い足す必要はないこと。この2点を伝えました。出席を止めないことを最優先にして、声が上がってから2日以内に実装を終えています。

出席カードは、スマホと並ぶ出席の方法として、製品の要件に加えました。スマホで読む経路も、そのまま残しています。設計の変更は、GrokとCodexの敵対的なレビューを通しました。あわせて、登録の決まりも見直しました。登録は、本人がしても親がしてもかまいません。必須にするのは、動物のマークだけです。マークは、あとから何度でも変えられます。

9月6日、テスト環境で生徒2人分の出席カードを自分で印刷して、読み込みからテストしました。目標は、月曜の9月7日から使えること。受付のカメラが起動していれば、そこにかざせばいいと分かる。コロナ禍の検温カメラで、みんなが覚えたことです。以後、テスト校では出席カードが使われています。

9月9日、ChatGPTをProに上げました。

8. 何を任せ、何を残したか

この半年で、AIに任せる範囲はもう一段広がりました。技術判断はエージェントが決めて記録し、価値判断だけが私に上がってくる。体制は、仕様と検証がClaude、敵対レビューがCodex、定型の実装がGrok、決定が私です。

残したのは、価値判断です。利用者が誰か。どの端末で何を開いてよいか。納期を完成の定義に入れるか。現場の事実を受けて設計を変えるか。どれもAIは決められませんでした。

この2年半で作り、いま人に使われているものを、時系列で並べます。

uniのコードは、9月17日時点で物理行145,923、非空行135,582です（追跡ファイルのみ。依存パッケージ・ビルド出力・minify済み・lockファイルを除外した実測）。

塾の出席管理とシフリーは、身近な教室を支えるものです。こどもの進路案内所とuniは、その活動を外へ届けるものです。塾の出席管理を作り始めたころの構想が、別の教室で動いています。

1年早かったら、今みたいなことはできていないと思います。2024年2月に無料のChatGPTで請求書を自動化してから、2026年9月まで。AIに払った金額は、累積で約29万円です。前半から通して、1枚の表にまとめます。

AIに任せる範囲は、広がりました。それでも、誰のために作るのか。誰が使うのか。どのように使うのか。何を求めているのか。それを、どうシステムに落とし込むのか。そこは、まだ私の手で握っています。