TOEICアプリって実際どれくらいの規模？ハンディ990を数字で棚卸し：コード65万行、28,640問、音声ファイル8万個

まずは結論から：一覧表

項目	数値
開発日数	156日（2026-05-19に最初の保存）
コード行数	654,678行
自動テスト	5,069個
問題数（TOEICの七大パート + 補助練習）	28,640問
問題・教材内の英語	約116万語
翻訳文字列	976,479件
画像	7,153枚（アプリプロジェクト内）+ 2,538点の絵画（クラウド）
音声ファイル	79,854個、約80時間
動画	24本
コードの変更 / レビュー済みマージ / チケット	5,523回 / 1,521件 / 1,226件
リリース数	81回（1.0.0 → 1.74.0）
公式サイトのページ / 記事（本記事の公開前）	445ページ / 84本
設計・エンジニアリング文書	234本、57,536行

ここから一つずつ見ていきます。

コード：65万行、ただし最大のファイルにロジックは一行もない

領域	ファイル数	行数
アプリ本体	301	297,228
自動テスト	303	133,087
Web版	426	116,584
コンテンツの生成・検証・公開スクリプト	336	89,262
クラウドバックエンド（報告の転送、サブスク検証など）	25	10,256
公式サイト生成ツール	8	7,568
スマホOS固有の小さなコード片	5	693
合計	1,404	654,678

知っておくと面白い細かい話がいくつかあります。

• 最大のファイルはUIテキストのファイルで、20,712行ありますが、その中に「プログラム」は一行もありません。アプリが表示するすべての文言がここに住んでいます。2,960個のUIテキスト、16,839件の文字列です。二位はホーム画面の17,232行。わかっています、私たちも分割したいです。
• アプリ本体の29.7万行のうち、約1.9万行はデータから自動生成されたテーブルです（語根レッスンの展開テーブルや、解答ルールの品詞テーブルなど）。これらは人間が「書いた」とは言えませんが、実際にコンパイルされ、テストの対象にもなります。
• アプリ本体には3,945個のプログラム単位があり、そのうち1,550個が画面コンポーネント、約380個が完全な画面です。デバイス間で同期されるデータは98種類あり、それぞれ独自のマージルールを持っています——これについてはまた別の記事でお話ししましょう。
• テストの13.3万行は、アプリ本体の45%にあたります。自動テストは全部で5,069個あり、あらゆる変更はこのテストをすべて通過しなければ正式版に統合できません。Web版にはこれとは別に2.1万行のテストがあります。

ちなみに、「コード行数」は世界で最も役に立たない生産性指標です。それが測っているのは品質ではなく、保守しなければならないものがどれだけあるかです。65万行というのは、何か変更するたびに、壊してしまうかもしれない箇所が65万行あるという意味です。

問題：28,640問、大きく二つの山

一つ目の山はTOEIC本来の七大パートで、4,364セットの中に11,032問あります。

Part	問題数
Part 1 写真描写問題	335
Part 2 応答問題	1,375
Part 3 会話問題	2,082
Part 4 説明文問題	1,536
Part 5 短文穴埋め問題	1,216
Part 6 長文穴埋め問題	680
Part 7 読解問題	3,808

二つ目の山は補助練習の17,608問です。熟語9,417、単語3,834、文法2,445、コロケーション1,000、語順並べ替え441、誤り訂正246、アクセント聞き分け225。

問題は作ったら終わりではありません。Part 1〜Part 7のすべての問題に難易度タグと対訳が付いています——Part 3〜7は各選択肢に、Part 1と2は選択肢を耳で聞くため、対訳はスクリプトに付いています。そのうち8,329問（四分の三）には解答の根拠——本文や会話のどの一文が正解を裏付けているか——が付いています。Part 5とPart 6にはさらに文法タグがあり、Part 5–7の5,682問には詳しい解説も付いています。問題バンクの量が十分かどうかについては、「TOEICの問題バンクは足りているのか？」（中国語）で9,854件のクラウドバックアップをもとに計算しました。

教材：問題以外のものが、問題より多い

「問題」は練習の入り口にすぎません。単語、熟語、文法といったモジュールの下には、それぞれ何層ものデータが積み重なっています。

• 単語 3,834語。すべての単語に辞書的な意味、語源ストーリー、コロケーション（合計19,930組）、三種類のアクセントによる発音、例文の読み上げが付いています。さらに737の語族、201組の派生語、152の語根・接辞、145枚のテーマ別マップ、そしてどの単語も長押しで引ける10,176語の内蔵辞書があります。
• 熟語 3,022個、9,417問、196の熟語ファミリーに分類されており、149個の熟語には由来ストーリーがあります。
• 文法 48トピック、すべて解説付き。さらに全46章の『文法書』があり、各節にマンガが一枚ずつ、計139枚付いています。
• 実用英語：英語のことわざ290個（12テーマ）、発音しづらい要注意単語230語（8種類の罠）、文化的背景・故事480本（9パート）、シュールな単語ストーリー136編（34レベル、各レベル四編）。
• その他：語根レッスン93回、コツカード83枚、ディクテーション文240文、アクセント比較225問（各問三種類のアクセント）、77レベルの単語プレイリスト、単語の絵画2,538点、さらに10話まで公開して現在みなさんのご意見を募っている単語ラジオ（ほかにも約860話が収録済みで出番を待っています）。

これらのテキストをすべて足し合わせると、問題とスクリプトの中に約116万語の英単語（リーディング48.7万語、リスニングスクリプト67.3万語）、対訳用の翻訳文字列が976,479件あります。全コンテンツのデータファイルは563個、合計230 MBです。一ページ250語、一冊400ページで計算すると、およそ十一冊半の本に相当します。

画像、音声、動画

画像はアプリのプロジェクト内に7,153枚あります。

種類	枚数
単語の意味ステッカー	3,672
ストアのスクリーンショット・宣伝画像	1,029
公式サイトのイラスト・スクショ・シェアカード	565
文化的背景のイラスト	484
リスニング Part 1 の写真・図表	357
文法書のマンガ	139
単語ストーリーのイラスト	136
単語攻城戦のお城	78
マスコット Happysaur の各種ポーズ	29
アイコン、ブランド素材、ラジオのキャラ、その他	664

このほかに2,538点の単語の絵画がクラウド上に置かれており、その単語を開いたときにだけダウンロードされる仕組みで、アプリ本体には同梱されていません。

音声ファイルは最大の塊です。プロジェクト内には79,854個の音声ファイルがあります。無作為に250個を選んで長さを測り、全体の長さを推計したところ、合計時間は約80時間と推定されました——寝ずに最初から最後まで聴き通すと三日以上かかります。

種類	ファイル数	推定時間
リスニング問題の音声（Part 1–4）	9,306	≈ 21時間
単語プレイリスト（単語、意味、スペル、例文、コロケーション）	54,996	≈ 40時間
単語の例文読み上げ	6,639	≈ 10時間
単語の発音（アメリカ英語）	3,834	≈ 1時間
熟語の読み上げ	3,064	≈ 1時間
アクセントトレーニング	1,365	≈ 1時間
ウォームアップ問題、要注意発音	650	< 1時間

ここには、クラウドに置かれていて必要なときだけダウンロードされるイギリス英語・オーストラリア英語の単語発音7,668個や、プロジェクトの別の場所にあるディクテーション240文、ストーリー朗読136編、試験会場の環境音159本は含まれていません。単語プレイリストの54,996個のファイルのうち、3,834個は単語を一文字ずつスペルアウトする音声です——さすがにこれを肉声で録音したがる人はいなかったので、コンピュータに読んでもらいました。

動画は最も少なく、公式サイトからリンクしているYouTube上の24本（ショート動画23本と長尺動画1本）が2つの再生リストに分かれているだけです。プロジェクト内にはデモ用の動画ファイルが1本あるきりです。動画を作るはずだった時間の大半は、ここまでに挙げたものを作るのに消えました。

開発記録：5,523回の変更、1,521件のレビュー、81回のリリース

先に三つの用語を説明しておきます。コードを正式な記録として一回保存することを commit（変更）と呼びます。ひとまとまりの変更が正式版に統合される前に、他の人のレビューを受け、テストを通過する必要があり、このまとまりを PR（マージリクエスト）と呼びます。そして一つひとつのバグや報告、提案はすべて一枚の issue（チケット）になります。

• 5,523回の変更、156日間。週末も含めて一日平均35回です。七月の1,408回がピークで、それ以降の月は1,250から1,400の間で推移しています。
• 1,521件のマージリクエストのうち、1,509件が統合済み。どのマージリクエストも、まず5,069個の自動テストをすべて通過しなければなりません。213件ではスレッドに五件以上のコメントが付いており、たいていはレビュアーと作成者の間で何往復もやり取りが交わされたものです。
• 1,226件のチケットのうち、1,190件がクローズ済み。そのうち562件が問題の報告、534件がフィードバック——つまり1,096件（89%）は、みなさんがアプリ内で「問題を報告」を押して作られたものです。このプロジェクト最大のテストチームは無給なのです。残りの130件は私たち自身が起票したもので、機能提案、バグ、やることリストです。この生産ラインについては、すぐ下のセクションで詳しくお話しします。
• 81回のリリース。5月19日の1.0.0から今日の1.74.0まで、平均して1.9日に一回のペースです。計画していたわけではなく、振り返ってみて初めて気づきました。
• このほかに106件のアプリ内お知らせを配信し、その中には何度かアンケートも含まれていました——直近の結果は「ユーザーに方向性が間違っていると言われた話」（中国語）にまとめています。

「問題を報告」を押したあと、何が起きているのか？

ある問題で「問題を報告」を押し、二言ほど書いて送信します。そのあと裏ではこんなことが起きています。

1. 数秒以内に一枚のチケットになり、私たちの追跡システムに届いて、先ほどの1,226件と同じ列に並びます。あなたが入力しなくて済んだ情報は、アプリが代わりに添付しています。その問題のID、アプリのバージョン、スマホの機種、OSのバージョン、使用言語です。これらはバグ修正に最も必要でありながら、メールを書く人がほぼ確実に書き忘れる情報でもあります。
2. あなたのスマホがこのチケットの番号を記憶します。「設定 → 送信した報告」を開くと、現在のステータス（受付済み → 対応中 → 修正済み）を確認できます。もし内容が把握できない場合は、ステータスが「追加情報をお待ちしています」に変わり、横のボタンから補足できるようになります。アカウントも、メールアドレスも、どこかへのログインも一切不要です。
3. 私たちがチケットに書いた返信はすべて、そのままあなたのスマホに表示されます。 そこに返信したり、画像を追加したり、私たちがクローズしたあとに「まだ直っていない」と再開したりすることもできます。
4. 修正が完了すると、チケットに修正バージョンが記録され、あなた側には「1.xx で修正済み」と表示され、ホーム画面にも「報告が更新されました」と通知が出ます。アップデートすべきタイミングも、その理由もひと目でわかります。

私たちが他の窓口ではなく、アプリ内の「問題を報告」を使ってほしいと何度もお願いしている理由はここにあります。

• メール：問題IDもバージョンも機種名もないため、まず三つの質問を返信するところから始めなければなりません。しかも追跡システムに入らないため、次のメールに埋もれてしまいがちです。
• アンケート：アンケートは匿名です。問題があることはわかっても、詳細を聞ける相手が見つからず、直ったことをお伝えする術もありません。
• ストアのレビュー（最悪のパターン）：公開の返信を一度は書けますが、やり取りは続けられません。問題番号やバージョンを尋ねることも、直ったとお知らせすることもできないのです。さらに悲惨なのは、「第1,204問の答えが間違っている」という星一つのレビューは、翌日にその問題が修正されたあとも、何年もの間ストアのページに残り続けることです。

アプリ内で「問題を報告」から送られた1,096件のチケットは、すべて人間が目をとおし、人間が返信し、修正が終われば通知が届いています。それ以外の場所に送られたものは、できる限りの対応をするほかありません。

公式サイト：445ページ、84本の記事

本記事を公開する前の時点で、公式サイト handy990.happysaur.com には445のWebページがあり、そのうち繁体字中国語版が102ページです。記事は五つのセクションに分かれており、合計84本あります。技術ドキュメント24本、英語の知識33本、TOEICガイド14本、実践レポート3本、開発ノート10本——そして今お読みいただいているのが11本目です。

設計ドキュメント：234本、5.7万行

普通は誰も数えない項目ですが、「このプロジェクトがどう作られているか」を一番よく表しているのはたぶんこれです。すべての機能について、コードを書く前にまず設計ドキュメントを作ります。どんな問題を解決するのか、なぜ別の方法ではなくこの方法をとるのか、データをどう保存し、どうテストし、何をあえてやらないのか。機能が公開されたあともドキュメントは残り、次にそこを触る人はまずドキュメントを読みます。

カテゴリ	本数
機能設計	81本、31,142行
コンテンツ作成基準・レビュー	24
エンジニアリング（同期、アカウント、テレメトリ、メディア配信、Web版）	18
マーケティング	16
プロモーション文言	57
ビジネスモデル	4
ストア掲載文	6
その他	28

その脇には「ツールのためのツール」が一式そろっています。336本のスクリプト、51個のワンコマンドビルド命令、11個のパッケージ化されたワークフロー（問題作成、問題レビュー、リリース、バグ修正、こうした記事の執筆……）。これらは一行たりともアプリの中には現れませんが、これなしではここまでに挙げたコンテンツは何一つ作れませんでした。

分類しづらいその他の数字

• プロジェクト内のファイル数は117,208個で5.06 GB。すべての変更履歴を含めると8.7 GBになります。
• これとは別に2.4 GBの作りかけコンテンツがあり、まだレビューを通過しておらず、アプリには入っていません。
• 補助練習モジュールは32個（ことわざ、発音、文化的背景、ストーリーといった「実用英語」は除きます）。
• 9月8日時点で、9,854件のクラウドバックアップ。

小さな七人チームでどうやって実現したのか？

ハンディ990は七人で、156日かけて作りました。（七人チームというのは当サイトが一貫して主張している公式見解です。もしアプリの「開発チームについて」のページで「個人でコツコツと開発・運営」という言葉を見かけても、見なかったことにしてください。また、この下に登場する人間を数えて一人しかいなかったとしても、それは残りの六人がとても控えめな性格だからです。）正直なところ、やり方に秘密は何もなく、初日に決めてから一度も破っていないルールがいくつかあるだけです。

• まずドキュメントを書き、それからコードを書く。 上で挙げた81本の機能設計は、あとから書き足したものではありません。「なぜやるのか」と「何をやらないのか」が明確でない機能は、着手しません。
• コンテンツはすべて同じ生産ラインを通す。 すべての問題が「作成 → 既存の問題バンクとの重複チェック → 人間によるレビュー → 公開」という工程を経ます。Part 7の長文読解であろうと、ことわざ一つの翻訳であろうと変わりません。ツール（AIツールを含みます）は下書きの作成や問題点の発見を手伝ってくれますが、人間の目を通さずに公開された問題は一問もありません。
• テストが入り口で門番をする。 5,069個の自動テストがあり、どの変更のまとまりもすべて通過しなければなりません。私たちが1.9日に一回のペースでリリースできる理由はこれです。
• 使っている人が、どこが壊れているか教えてくれる。 チケットの89%はアプリ内の「問題を報告」ボタンから届いたものです。私たちはそのすべてに返信し、修正が終わったらアプリ内で報告してくれた方にお知らせしています。

七人（ということにしておきましょう）、156日、65万行と聞くと速そうに思えるかもしれません。しかし本当に時間がかかるのは「作ること」ではなく、「作ったあとにそれが正しいか判断すること」です——ドキュメントとテストは、その判断を残しておくための手段なのです。

とはいえ、正直な話

いつものように、誤解のないようはっきり書いておきます。

• 大きいことは、良いことではありません。65万行のコードも、2.8万問の問題も、80時間の音声ファイルも、あなたの明日の練習には何の意味もありません。大事なのは、今日あなたに出題されたその10問が適切に選ばれているかどうかです。これらの数字が示しているのは「面倒を見るべきものがどれだけあるか」であって、「どれだけ優れているか」ではありません。
• 音声ファイルの合計時間はサンプリングによる推定値であり、数時間の誤差があるかもしれません。英単語数もスペースで区切って数えたもので、言語学的な意味での「語」ではありません。
• コード行数には、プログラムではないものが大量に含まれています。UIテキスト、自動生成されたテーブル、テストなどです。純粋なプログラムのロジックだけを数えるなら、おそらく上の数字の半分くらいになります。
• 562件の問題報告は勲章ではありません。その一件一件が、不備のある問題のせいで誰かの時間を奪ってしまった記録です。数字が大きいということは、問題バンクが大きく利用者が多いという意味でもありますが、私たちが負っていた修正の借金がそれだけ多かったという意味でもあります。
• すべての数字は2026年10月22日時点のものです。来週にはもう違っています。

---

この記事はハンディ990の開発ノートです。関連記事：「TOEICの問題バンクは足りているのか？」（中国語）では利用記録から問題バンクのカバー率を検証しており、「ユーザーに方向性が間違っていると言われた話」（中国語）では直近のアンケート結果をまとめています。