非エンジニアが出張精算フォームを自作してGitHub Pagesで公開するまで

こんにちは。合同会社多田EC支援事務所の多田優之です。

今回は、普段の企業支援とは少し毛色の違う話です。自社の「出張報告書兼旅費精算書」を、生成AIの力を借りながらゼロから作り、GitHub Pagesで本格運用するまでの記録を書きます。

私は文系出身の非エンジニアです。プログラミングの勉強は独学で、生成AIを使いながら試行錯誤で進めています。同じような立場の方に「自分にもできるかも」と思ってもらえたら嬉しいです。

※操作環境は、Mac Mini、MacBook Proです。

今回出てくる専門用語のかんたん解説

この記事にはIT用語がいくつか出てきます。ITに詳しくない方でも読めるよう、先にまとめておきます。全部覚える必要はありません。「こんなものがあるんだな」くらいで大丈夫です。

プログラミング・開発に関する用語

ツール・サービスに関する用語

操作・作業に関する用語

ここまでの経緯（なぜ自作に至ったのか）

今の形にたどり着くまでには段階がありました。

第1段階：Googleフォーム＋スプレッドシート（2021年3月〜）※法人化で

最初は、Googleフォームで出張データを入力し、スプレッドシートに自動記録する運用でした。基本的な記録はできていましたが、日当の自動計算や複数の出張区分への対応など、少し複雑なことをやろうとすると手計算が必要でした。

第2段階：AppSheetの活用（約2年間）

次に試したのが、GoogleのAppSheetです。スプレッドシートのデータをもとにフォームや一覧画面を自動生成してくれるツールで、ノーコードで作れるのが魅力でした。約2年間使い、出張区分マスターとの連携なども実現でき、実務上は十分に効率化できていました。

ただ、AppSheetの管理画面がすべて英語であることや、シート名を変更するとテーブル定義との紐づけが切れてエラーになるなど、非エンジニアにはトラブルシューティングが難しい場面もありました。

第3段階：CodeSandbox＋GAS＋スプレッドシート

その後、GASの学習を進める中でCodeSandboxというオンライン開発環境を知りました。生成AIにコードの作成を相談しながら、Reactで入力フォームを自作。GAS経由でスプレッドシートに書き込む仕組みを作りました。

AppSheetでは難しかった画面デザインの自由度や、計算ロジックの柔軟さが手に入り、自分の業務にぴったり合ったフォームが作れるようになりました。

第4段階：GitHub Pagesへの移行（今回の話）

CodeSandboxで十分に動作確認ができたので、本格運用のためにGitHub Pagesへ移行しました。今回のブログはこの移行作業の記録です。

全体の構成

今回のシステムは3つの要素で成り立っています。

入力フォーム（React + TypeScript）

出発日、帰着日、目的地、業務内容、移動手段、出張区分、実費精算など、出張に必要な項目を一画面で入力できるフォームです。出張区分を選ぶと日当が自動計算されます。交通費（Yahoo!路線情報で調べた金額）は手入力です。スマートフォンでも使えるレスポンシブ対応にしています。

送信処理（Google Apps Script）

フォームの「保存」ボタンを押すと、GASのWebアプリにデータが送られます。GAS側ではトークン認証（合言葉チェック）と重複送信防止を実装しています。

データ保存先（Googleスプレッドシート）

GASが受け取ったデータをスプレッドシートに1行ずつ追記します。あとはスプレッドシート上で集計や確認ができます。

移行の手順

実際にやったことを順番に書きます。

1. 開発環境の準備

まず、以下の3つをインストール・設定しました。

• GitHub：ソースコードの保管場所（アカウント作成）

• GitHub Desktop：GitHubとのやりとりを画面操作で行うアプリ

• VS Code：コードを編集するエディタ

GitHubには無料プランと有料プラン（Pro：月4ドル）があります。私はプライベートリポジトリ（ソースコードを非公開にする設定）でGitHub Pagesを使いたかったので、Proプランにしました。

2. Node.jsのインストール

Reactのプロジェクトをビルドするために、Node.jsが必要です。公式サイト（https://nodejs.org/）からLTS版（安定版）をダウンロードしてインストールしました。

Macの場合、VS Codeのターミナルでnpm installと打って反応があればインストール完了です。ちなみに私の環境では最初「npm: command not found」と表示されて焦りました。Node.jsがまだ入っていなかっただけでした。

3. リポジトリの作成とコードのコピー

GitHubでプライベートリポジトリを作成し、GitHub Desktopで自分のPCにクローン（コピー）。VS Codeで開いて、CodeSandboxのコードを手動でコピーしました。

ファイル構成はこんな感じです。

business-trip-report/
├── public/
│   └── index.html       ← Webページの土台
├── src/
│   ├── App.tsx          ← フォーム画面のメインコード
│   ├── index.tsx        ← アプリの起動ファイル
│   └── styles.css       ← デザイン（色、余白など）
├── package.json         ← 必要なライブラリの一覧
├── tsconfig.json        ← TypeScriptの設定
└── .gitignore           ← GitHubに上げないファイルの指定

.gitignoreにはnode_modulesとbuildを記載しています。node_modulesはライブラリのファイルが何万個も入るフォルダで、これをGitHubにアップロードしてしまうとリポジトリが非常に重くなります。npm installコマンドでいつでも再生成できるので、GitHubには上げません。

4. ビルドとデプロイ

VS Codeのターミナルで以下のコマンドを順番に実行します。

npm install              ← 必要なライブラリをダウンロード
npm run build            ← ソースコードをWebページ用のファイルに変換
npx gh-pages -d build   ← 変換済みファイルをGitHub Pagesに配置

npm run buildが成功すると「Compiled successfully.」と緑色で表示されます。この表示が出ない場合はコードにエラーがあるので、デプロイしてはいけません。

npx gh-pages -d buildが成功すると「Published」と表示されます。

5. GitHub Pagesの設定

GitHubのリポジトリ設定（Settings → Pages）で、ソースを「Deploy from a branch」、ブランチを「gh-pages」に設定して「Save」。数分待つとURLが有効になり、ブラウザからフォームにアクセスできるようになります。

セキュリティ面で気をつけたこと

業務ツールなので、セキュリティには注意を払いました。

GitHubリポジトリはプライベート設定

ソースコードはGitHub上では自分しか見られません。GASのURLやトークンがコードに含まれているため、プライベートにしておくことが重要です。GitHub Pagesで公開されるのはビルド後のファイル（変換済みのHTML/CSS/JS）だけです。

GAS側でのトークン認証

フォームからGASにデータを送信する際、事前に決めたトークン（合言葉）をチェックしています。トークンが一致しない送信は拒否されます。

重複送信の防止

リクエストごとに一意のIDを発行し、同じデータが二重に登録されることを防いでいます。

スプレッドシートへのアクセス制限

GASは書き込みのみ実行する構成です。仮にGASのURLが知られたとしても、既存のデータを読み出すことはできません。

トークンやAPIキーの管理

トークンやURLなどの機密情報は、Googleスプレッドシートで管理台帳を作成し、自分だけがアクセスできる設定にしています。将来的にはパスワードマネージャーのセキュアノートに集約していく予定です。

つまずいたポイント

非エンジニアならではの苦労もありました。同じ道を歩む方の参考になれば。

ターミナルに対する心理的ハードル

黒い画面にコマンドを打つのは最初怖かったです。でも、今回使ったコマンドは実質3つだけ。慣れると「保存して、変換して、公開する」という3ステップでしかないことが分かります。

ファイルの未保存でビルドエラー

VS Codeで編集した後に保存し忘れてビルドすると、古い内容のままビルドされます。ファイル名の横に「●」マークが表示されていたら未保存のサインなので、⌘+Sで保存してからビルドしてください。

スプレッドシートのタブ名とGASの不一致

GASのコード内にあるSHEET_NAMEと、スプレッドシートの下に表示されるタブ名がずれていると「sheet_not_found」エラーになります。タブ名を変えたらGASのコードも変えて再デプロイ、が鉄則です。

GASの参照先スプレッドシートの変更

テスト用と本番用でスプレッドシートを分けていた場合、GASのコード内でどのスプレッドシートに書き込むかを明示的に指定する必要があります。スプレッドシートのURLに含まれるIDを使って指定します。

node_modulesをコミットしそうになった

.gitignoreファイルを作り忘れた状態でGitHub Desktopを見たら「37,036 changed files」と表示されて驚きました。ライブラリのファイルが全部コミット対象になっていたのです。.gitignoreを作成してnode_modulesとbuildを除外したら、変更ファイルは10個程度に収まりました。

今後のコードの更新手順

フォームを修正したいときの手順をまとめておきます。

1. CodeSandboxでコードを修正・動作確認する

2. VS Codeの各ファイルに修正内容をコピーする

3. すべてのファイルを保存する（Mac：⌘+S）

4. ターミナルでnpm run buildを実行する（「Compiled successfully.」が出ればOK）

5. ターミナルでnpx gh-pages -d buildを実行する（「Published」が出ればOK）

CodeSandboxは「下書き・テスト用」、GitHub Pagesは「本番用」という使い分けです。VS Codeでの編集に慣れてきたら、CodeSandboxを経由せずに直接VS Codeで修正することもできます。

まとめ

文系・非エンジニアでも、生成AIを活用すれば業務ツールを自作して本格運用できる時代になっています。

ここまでの道のりを振り返ると、Googleフォームから始まり、AppSheetで約2年間効率化し、CodeSandboxで自作フォームを作り、最終的にGitHub Pagesで安定運用にたどり着きました。一足飛びにここまで来たわけではなく、それぞれの段階で学びがありました。

大事なのは「完璧を目指さず、まず動くものを作る」ことと、「セキュリティは最初から意識する」ことだと思います。

私は普段、中小企業や商工会向けにECや生成AIの活用支援を行っていますが、こうした実体験があるからこそ「実際にやってみた人」として具体的なアドバイスができると考えています。

「うちの会社でもこういうの作れないか」「業務のこの部分を自動化したい」といったご相談がありましたら、お気軽にお問い合わせください。

※この記事は2026年2月時点の情報です。各サービスの仕様は変更される可能性があります。