「AI開発」を、事務所の共通言語に。
外部エンジニアと、同じ地図で話す。

DXとは、紙の書類をPDFにすることではありません。それは仕事の「やり方そのもの」を変えていく取り組みです。

もちろん、紙をスキャンしてPDFにする、手書きの台帳をExcelに移す——こうした「道具のデジタル化」も第一歩としては大切です。ですがDX（デジタル・トランスフォーメーション、＝デジタルによる変革）が本当に目指すのは、その先。「申請書をいったん印刷して、印鑑をもらって、また入力し直す」といった流れそのものを見直し、もっと速く・もっと正確にできる形へ作りかえることです。

いまは、未経験者でも「小さな業務アプリ」を作れる時代

かつてアプリ作りは、専門のエンジニアだけのものでした。ですが今は、Claude Code や Codex といったAIに日本語で頼むだけで、プログラミング未経験のスタッフでも小さな業務アプリを形にできます。たとえば「顧問先ごとの申請の進捗を一覧で管理する画面」のようなものを、自分たちの手で。

AIに正しく指示する。外部エンジニアや外注先と打ち合わせる。出てきた見積もりや提案の意味を理解する。そのすべてに、共通の地図と言葉が要ります。同じ言葉・同じ思考で話せること——これがDXの大前提なのです。

この教材は「用語 → 構造 → 実践」の3段で進みます

まず言葉を知り、次に全体がどう組み合わさっているかをつかみ、最後に実際に作って公開する。この順番で進めば、知識がきれいに積み上がっていきます。下の3ステップが、この教材の歩き方です。

1. 用語を知る
   「サーバー」「データベース」など、AIやエンジニアが当たり前に使う言葉を、社労士業務にたとえながら一つずつ理解します。まずは"聞いたことがある"状態を目指します。
2. 全体の構造をつかむ
   受付（画面）・奥の事務処理（プログラム）・顧客台帳キャビネット（データベース）が、どうつながって一つのアプリになるのか。仕組みの「見取り図」を頭に入れます。
3. 作って公開する
   AIに頼みながら小さなアプリを作り、実際にインターネットへ公開するところまで体験します。手を動かすことで、言葉と構造が一気に腑に落ちます。

言葉が通じれば、仕事は変えられる。

そもそもWebアプリとは

Webアプリとは、ブラウザ（Chrome や Edge など）で開いて使うソフトのことです。インストール不要で、URLを開けばすぐ使えます。実は、いつも使っている給与計算や勤怠管理のクラウドサービス（SaaS）も、その正体はWebアプリです。

3つの役割 ― 受付・奥の担当・台帳キャビネット

Webアプリは、大きく3つの層に分かれて働いています。お客様の目に映るのは一番上の「受付」だけ。裏側では、奥の担当者が計算や判断を行い、台帳キャビネットが情報を保管しています。上から順に重なったこの3層が、Webアプリの基本構造です。

画面と裏方の往復 ― リクエストとレスポンス

フロントとバックは、つねに「お願い」と「お返事」をやり取りしています。利用者が画面で操作すると、フロントが裏方へ依頼（リクエスト）を送り、バックが処理して結果（レスポンス）を返し、画面に表示されます。この往復が、Webアプリの基本動作です。

フロントを作る3つの言語

受付（フロント）は、役割の違う3つの言語を組み合わせて作られています。それぞれの分担は次のとおりです。

お客様は受付としか話さない。けれど、答えを出しているのはいつも奥の担当者である。

「動いた／動かない」「見える／見えない」「消える／消えない」――その答えは、いつも“どの場所の話か”で決まります。

同じ「アプリ」という言葉でも、それがどこで動いていて、データがどこに保存されているかで意味はまったく変わります。まずは3つの場所を、ひとつずつ整理しましょう。

① ローカルホスト（手元のPCの中だけ）

ローカルホスト（localhost）とは、「自分のPCの中だけで動かしているお試し環境」のことです。ブラウザのアドレス欄には http://localhost:3000 のように表示されますが、この localhost は「いま自分が触っている、このPC自身」を指す言葉です。だから、ここで動いているアプリは他人には見えません。壊しても誰にも迷惑がかからない、安全な砂場（すなば）だと考えてください。

② デプロイ（インターネットに公開する）

デプロイとは、手元で作ったアプリをインターネット上に置いて、誰でも開けるようにすることです。https://〜.vercel.app のような正式なURLが付き、お客様や同僚はこのアドレスからアクセスできます。「人に使ってもらえるのは、こちら」と覚えてください。

③ 本番データベース（クラウドの共有保管庫）

本番DB（データベース）は、入力されたデータを自分のPCではなく、クラウド上の共有保管庫（Neon など）に保存するしくみです。誰がどこから使っても同じ最新データが見え、PCを閉じても、電源を切ってもデータは消えません。事務所の正式な台帳は、こちらに置きます。

見える人・データの置き場所・用途で整理

「データはどこにある？」を整理する

場所が分かれば、「いま誰の、何の話か」が分かる。

データベース（DB）とは ― 整理された保管庫

データベース（よく DB と略します）とは、検索・追加・更新・削除がすばやくできるように、きちんと整理されたデータの保管庫のことです。見た目はExcelの表によく似ていますが、何万件・何十万件という大量のデータでも速く正確に扱え、複数の人が同時に使ってもデータが壊れにくい、という強さを持っています。

テーブル・行・列 ― Excelの感覚でつかむ

データベースの中身は、Excelを思い浮かべると一気にわかりやすくなります。下の対応表のとおり、Excelのシートにあたるものを テーブル、1件1件のデータ（たとえば従業員1人分）を 行、氏名や基礎年金番号といった項目を 列 と呼びます。

SQL ― データベースへの「お願いの言葉」

データベースに「こういうデータを出してほしい」と頼むときに使う言葉を SQL（エスキューエル）と呼びます。たとえば「30歳以上の従業員を出して」「この従業員の住所を更新して」といったお願いを、決まった書き方で伝えるための言葉です。書き方を細かく覚える必要はまったくありません。「データベースには専用のお願いの言葉がある」とだけ知っておけば十分です。

なぜExcelやファイルではなく、データベースなのか

「Excelや共有フォルダのファイルでも管理できているのに、なぜわざわざデータベース？」と思うかもしれません。Excelが悪いわけではなく、手元の集計や下書きにはExcelが最適です。一方で、アプリが裏側で大量のデータを安全に扱うなら、データベースのほうが向いている理由があります。役割分担と考えてください。

Neonとは ― クラウドで使えるPostgreSQL

Neon（ネオン）とは、インターネットの向こう側（クラウド）で動くデータベースのサービスです。中身は PostgreSQL（ポストグレスキューエル、通称「ポスグレ」）という、世界中で広く使われている信頼性の高いデータベースです。サーバーレスという言葉で説明されますが、これは「サーバーが無い」のではなく、「自分でサーバーの面倒を見なくてよい」という意味です。無料枠はクレジットカード不要・期限なしで試せます（2026年6月時点。最新は公式 neon.com で確認）。

Neonの3つの特徴

DBブランチ ― 本番をいじらず安全に練習する

接続文字列 ― データベースにつなぐ「鍵付きの住所」

アプリがNeonのデータベースにつなぐには、接続文字列（connection string。多くは DATABASE_URL という名前で扱います）という1行の文字が必要です。postgres://… という形をしていて、「どこにある、どのデータベースに、どの鍵で入るか」がすべて詰まっています。つまり、これは住所と鍵がセットになった、たった1行の合言葉です。

接続の安全 ― ブラウザから直接つながない

ここが情報管理でいちばん大切な点です。利用者のブラウザ（フロント）から直接DBにつなぐのは危険です。必ずサーバー（バックエンド）を経由させ、サーバーが代わりにデータベースへ問い合わせます。通信は SSL/TLS で暗号化されます。

• データベースは「整理された保管庫」。Excelに似ているが、大量・同時・安全に強い。
• テーブル＝シート、行＝1件、列＝項目、と覚える。
• Neonはクラウドで動くPostgreSQL。サーバー管理が不要で無料枠から始められる。
• 接続文字列は合鍵。GitHubやコードに直接書かず、環境変数で秘密に扱い、ブラウザから直結しない。

git ＝ 超高機能な「元に戻す」

申請書類を直していて「やっぱり昨日の状態に戻したい」と思ったことはありませんか。git（ギット）は、ファイルの変更履歴をまるごと記録・管理する道具です。2005年に生まれ、いまや世界中のソフトウェア開発の標準になっています。ひとことで言えば、何百回でもやり直せる超高機能な「元に戻す（undo）」です。

4つの基本用語

commit ＝ 区切りのよい保存ポイント

キリのよいところで commit をすると、その瞬間のファイルの状態に「しおり」が挟まります。しおりには必ず短いメモ（メッセージ）を添えます。たとえば「給与計算表の残業単価を修正」。後から履歴を見れば、いつ・何のために変えたかが一目で分かり、必要ならその時点に丸ごと巻き戻せます。

branch → commit → merge の流れ

新しい作業を始めるときは、まず本体から枝分かれ（branch）させて、その中で安心して直します。仕上がったら本体へ合流（merge）させる。この一連の流れが、git のいちばん基本的な使い方です。

1. branch（ブランチを切る）
   本体（main）はそのままに、作業用の分身コピーを作る。ここで何をしても本体は無傷。
2. commit（こまめに保存）
   区切りのよいところで保存ポイントを作り、何を変えたかメモを残す。
3. merge（本体に合流）
   作業が完成したら、成果を本体へまとめて反映する。多くは git が自動で合わせてくれる。

conflict は「エラー」ではなく「お知らせ」

2人が同じファイルの同じ行を別々に直すと、git は「どちらを採用すべきか自動では決められません」と立ち止まります。これが conflict（コンフリクト）です。別々の行を直していれば、git が両方をきちんと取り込んでくれるので、起きません。

git と GitHub は別物

よく混同されますが、この2つはまったく別の道具です。git は手元のPCで履歴を記録する仕組み、GitHub はその記録をネット上で共有・保管する場所。次章で扱う push / pull / PR は、すべて GitHub 側（共有）の話です。

実務では AI が操作を代行してくれる

安心してください。コマンドを丸暗記する必要はありません。実務では Claude Code や Codex が、コミットやブランチ操作を代わりに実行してくれます。私たちに必要なのは考え方を知っておくこと。仕組みが分かっていれば、AIや外注エンジニアと同じ言葉で会話でき、指示も的確になります。

変更を恐れず、いつでも戻れる。git は「失敗していい安心」を仕事に持ち込む道具です。

前の章で学んだgitは、あくまで「手元のパソコンの中」で変更の履歴を残す道具でした。でも、それだけでは同僚と分け合えません。そこで登場するのがGitHubです。gitが記録した履歴をまるごとクラウド(インターネット上の保管場所)に置き、チームで共有・共同編集できるようにするサービスです。

まず覚える3つの言葉

PRとIssue ― 「回覧」と「付箋」

標準の進め方 ― GitHub Flow

少人数のチームで最も使われる、シンプルで安全な手順です。常に公開・正式版となるmain(メイン)はきれいなまま保ち、作業は必ず別のブランチ(作業用の枝)で行います。

1. 作業ブランチを作る
   正式版mainから枝分かれした作業スペースを用意する。ここで自由に直す。
2. commit する
   区切りのよいところで変更を記録(コミット)し、メモを残す。
3. push する
   作業ブランチをGitHubへ上げ、チームから見える状態にする。
4. Pull Request を出す
   「この変更を入れてよいか」と回覧をかけ、差分を共有する。
5. レビューを受ける
   同僚が差分を見てコメント・修正依頼。直して再度push。承認(承認印)が下りる。
6. merge する
   承認後、作業ブランチの変更を正式版mainへ反映する。
7. ブランチを削除する
   役目を終えた作業ブランチを片付け、棚をすっきり保つ。
8. pull で最新化する
   マージが終わったら、各自が git pull で main の最新を手元へ取り込み、次の作業を最新の状態から始める。共同編集の事故を防ぐ、最後の大切な習慣です。

無料でできること・権限の渡し方

GitHubは無料の範囲でも、外部に見えないprivate(非公開)リポジトリを無制限に作れ、招待する仲間(コラボレーター)の人数にも制限がありません(2026年6月時点。最新の条件は公式で確認)。招待する相手ごとに、どこまで触れるかを権限で選んで渡せます。

うっかりを防ぐ安全装置

一人で速く進むより、チームで確かに育てる。履歴と承認が、その安心を支える。

いまや、コードはエンジニアが一文字ずつ打つものではなく、AI開発アシスタントに「こう作って」と指示して一緒に組み上げるものになりました。代表が Claude Code（Anthropic社）と Codex（OpenAI社）。この2つを軸に、安心して使うための考え方を整理します。

二大ツール ― Claude Code と Codex

どちらも「あなたの手元のコードを直接読み、変更し、実行する」AIアシスタントです。基本はターミナル（黒い画面）ですが、VS Code やデスクトップアプリ、ブラウザ版でも使え、中身（エンジン）は同じです。2026年にかけて広く普及し、いまでは並ぶ二大ツールと各社から発表されています。

料金やプランは変わりやすいため、最新は各社の公式サイトで確認してください。Codexの無料枠は「お試し」程度で、日常的に使うなら有料プラン（または使った分だけの従量課金）になります。

いちばん大事なこと ― 成果物は“あなたのPC”に残る

AIに作らせたコードは、クラウドの中に閉じ込められません。あなたのPCのフォルダ（ローカル）に、普通のファイルとして保存されます。特定のAI専用の保存形式ではなく、gitで管理された“ごく普通のプロジェクト”です。

中央のキャビネット（フォルダ）は1つ。左右どちらのスタッフ（AI）も、同じキャビネットから書類を取り出し、同じキャビネットに書類を戻していくイメージです。

さらに前章で学んだGitHubに上げれば、別のPC・別のツール・別のメンバーからでも、同じ続きから作業を再開できます。ローカルが起点、GitHubが共有 ― この流れがそのまま活きます。

MCP ― AIを外部とつなぐ“共通の差込口”

MCP（Model Context Protocol）とは、AIを外部のツールやデータ（Google Drive・Slack・社内データベースなど）につなぐための“共通の作法”の規格です。USB-Cのように、1つの差込口の形を覚えれば、いろいろな相手につなげます。Anthropic社が提案し、2025年に主要各社（OpenAI・Google・Microsoftなど）が採用して業界標準になりました。

つなぐ相手と範囲は自分で許可します。給与・人事などの機微なデータをつなぐときは、後述の情報管理を必ず守ってください。

やってはいけないこと／安全に使うために

1. フォルダを決める
   AIに任せる作業用のフォルダ（キャビネット）を1つ用意する。機密は入れない。
2. 指示書を置く
   Claude Codeなら CLAUDE.md、Codexなら AGENTS.md に「何を作るか・守ること」を書く。
3. AIに作らせる
   1つのAIで“片方ずつ”進める。成果物はそのフォルダに普通のファイルとして溜まる。
4. 人がレビュー
   内容を確認し、問題なければ git でコミット。必要ならGitHubへ push。
5. ツールは乗り換え自由
   同じフォルダを別のAIで開けば、続きから作業できる。

道具（AI）は乗り換えられる。成果物（あなたのキャビネットの書類）は、ずっとあなたのものだ。

これまでの章で、コードを書き、GitHubに保存(push)する流れを学びました。では、そのアプリを「自分のPCの中だけ」ではなく「必要な人がブラウザから使える状態」にするには、どうすればよいのでしょうか。その答えがデプロイ(公開・配備)であり、それを驚くほど簡単にしてくれるのがVercel(バーセル)というサービスです。

Vercelとは ― コードを渡すだけで公開できる場所

Vercelは、作ったWebアプリをインターネット上に置いて動かすホスティング(=アプリの置き場所・実行環境を貸すサービス)です。最大の特長は、サーバーの細かい設定がいらないこと。本来なら専門知識が必要な「どのサーバーに置くか」「どう動かすか」をVercelが肩代わりし、私たちはコードを渡すだけで公開できます。

核心はGitHub連携 ― pushするだけで自動公開

Vercelが本領を発揮するのはGitHubとの連携です。一度つないでおけば、GitHubにコードをpushするたびにVercelが自動でそれを取り込み、公開してくれます。これを自動デプロイと呼びます。「公開ボタンを押す」「ファイルを手でアップロードする」といった手作業は、もう必要ありません。

プレビューデプロイ ― 公開前に確認できる安全装置

「直したいけれど、いきなり本番に出すのは怖い」。その不安にVercelはプレビューデプロイで応えます。本番とは別の一時的なURLを自動で作ってくれるので、正式に反映(マージ)する前に、所長や同僚と「この見た目で問題ないか」を確認できます。

環境変数 ― パスワードを安全に渡す

アプリには、データベースの接続情報やパスワードなど、人に見せてはいけない情報があります。これらをコードに直書きするのは厳禁です(GitHubに保存すれば外部に見えてしまう恐れがあるため)。代わりに使うのが環境変数です。Vercelの管理画面に登録しておけば、コードに秘密情報を書かずに、安全にアプリへ渡せます。

前章で登場したNeon(クラウドのPostgreSQLデータベース)の接続情報DATABASE_URLも、この環境変数として登録します。マーケットプレイス連携を使えば、こうした接続情報が自動で登録される仕組みもあります。

料金 ― 無料枠と、業務利用での注意点

Vercelには無料のHobby(ホビー)プランがあり、月100万回の関数実行などを無料で使えます(2026年6月時点)。ただし、ここに事務所にとって決定的に重要な注意点があります。

関連して知っておきたい ― Next.jsとv0

仕上げに、Vercel周辺でよく聞く2つの言葉を紹介します。どちらも「Vercelと相性が良い」のがポイントです。

保存するだけで、世界に届く。公開はもう、特別な作業ではありません。

ここまでで GitHub（コードの保管庫）・Vercel（公開して動かす場所）・Neon（データの保管庫）を別々に見てきました。この章では、その3つを一枚の地図にまとめます。名前が似ていて混同しやすいので、まずは役割をハッキリ分けることから始めましょう。

3つの道具を1枚に

覚え方はとてもシンプルです。「コードはGitHubから／データはNeonから／それをVercelが受け取って動かす」。この一文が頭に入れば、全体像はほぼ掴めたと言ってよいでしょう。

大事な整理 ― GitHubとNeonは直接つながらない

ここが一番の勘どころです。GitHub（コード）とNeon（データ）は直接つながりません。両者を橋渡しするのは、真ん中で動いている Vercel（公開アプリ）です。Vercelが「GitHubからコードを受け取り」「Neonからデータを受け取って」、両方を組み合わせて画面を作ります。

どこに「何」があるか

push したら自動で公開（おさらい）

日々の流れもシンプルです。手元のPCで直したコードを git push でGitHubに送ると、それを合図にVercelが自動で受け取り、公開アプリを最新版に更新します。これが 自動デプロイです。「保存して送る」だけで公開まで進む、回覧と承認印が自動で回るイメージです。

秘密の情報（接続文字列・APIキー）の置き場所

Neonにつなぐためのパスワードのような文字列（接続文字列）や各種 APIキー は、絶対にGitHubのコードに直接書いてはいけません。これらは 環境変数 として、VercelやNeonの管理画面側にそっと預けます。コードには「鍵を取り出す指示」だけを書き、鍵そのものは別保管にする、という考え方です。

費用の超概要

「いきなりお金がかかるのでは」という心配は要りません。学習や小規模なうちは、3サービスとも 無料枠 から始められます 無料枠あり。ただしVercelの無料プラン（Hobby）は個人・非商用が前提です。事務所の業務として本格的に商用利用へ進む段階では、Vercelは Pro（1人あたり月20ドル） が必要になります（2026年6月時点）。料金は変わりやすいため、進める前に最新は公式サイトで確認してください。

役割を分けて名前を呼べるようになった時、技術はもう「ブラックボックス」ではなく、あなたの地図の上にあります。

この章は、社労士事務所にとって最も大切な「守り」の章です。難しく身構える必要はありません。普段のダブルチェック文化や、キャビネットの施錠と同じ発想を、デジタルの世界に持ち込むだけです。

なぜ社労士は他業種より厳しいのか

私たちが日々ふれる情報を思い出してください。マイナンバー、給与額、健康診断やメンタル不調の記録、家族構成。これらは要配慮個人情報（取り扱いに特別な配慮が要る情報）や、法律で厳重な管理が定められたマイナンバーを含みます。だからこそ、AIやクラウドへ「何を渡すか」の判断基準は、一般の業種よりずっと厳しく設定する必要があります。

線引きの目安 ― 信号で考える

渡してよいかどうかは、信号機で考えると迷いません。緑＝安全な進め方、黄＝条件付き、赤＝原則渡さない、の3色です。

生成AIに個人情報を入れる2つのリスク

原則：入れる前に消す・置き換える（マスキング）

AIを安全に使うコツは単純です。マスキング（隠すこと）・匿名化（誰か分からなくすること）をしてから渡し、AIの答えに手元で本物を当てはめ直すのです。

主要AIの「学習に使われるか」設定（2026年6月時点）

シークレット（APIキー・接続文字列）の守り方

シークレットとは、AIやクラウドに接続するための「鍵」にあたる文字列です。これが漏れると、他人があなたの名義でサービスを使い、料金や情報が流出します。守り方には決まった手順があります。

1. コードに直書きしない
   鍵をプログラム本文に書くと、ファイルを共有した瞬間に漏れます。絶対に避けます。
2. 環境変数や .env に書く
   鍵は専用の .env という設定ファイルにまとめて書き出します。
3. .gitignore で .env をGitHubに上げない
   共有対象から除外する指示書（.gitignore）に .env を登録します。
4. 中身を空にした .env.example を共有
   「ここに鍵を入れてね」という空の見本だけを仲間に渡します。

もし鍵を公開してしまったら

クラウドの安全 ― 封筒と金庫

クラウドにデータを預けるとき、2つの暗号化が守ってくれます。通信中はTLS、保管中はAES-256という強力な方式で暗号化されます。

法律の押さえどころ

実例から学ぶ ― 「社労夢」ランサムウェア事件

クラウド型の社労士業務システム「社労夢」（エムケイシステム）がランサムウェア（データを人質に取る攻撃）の被害を受け、管理されていた最大約2,242万人分の個人情報が暗号化・流出の危機にさらされました。これを受けて2024年3月、個人情報保護委員会はエムケイシステムに行政指導を行いました。このとき、システムを利用していた約57万事業所が「委託している自覚なく」従業員データを預けていた状態が問題視されました。

迷ったときのQ&A

この章の鉄則

• まず本物の個人情報を一切使わず、ダミーデータ（架空の氏名・番号）で作る
• 動いて安全が確認できてから、本番データへ移す
• マイナンバー・要配慮個人情報・生の名簿は、無料の個人向けAIに渡さない
• シークレットはコードに直書きせず、.env を .gitignore で守る
• 鍵を漏らしたら、消す前に「無効化して再発行」
• クラウドは「預けた先を監督する責任」を忘れない

安全は「足かせ」ではなく、顧問先からの信頼を守る「土台」。まずダミーで、安心してから本番へ。

「小さな業務アプリ」とは何か

大きなシステムを一から作る必要はありません。小さな業務アプリとは、事務所の困りごとをたった1つだけ解決する、手のひらサイズの道具のことです。AIに頼めば、プログラミング未経験でも数十分〜数時間でたたき台（試作）を作れる時代になりました（2026年6月時点）。

代表的なユースケース ― まずはこの中から1つ

社労士業務でよくある困りごとは、たいてい次のどれかに当てはまります。「これ、毎月手作業でやっているな」と思うものを1つ選んでください。

難易度の低い順 ― どこから手をつけるか

最初は「やさしいもの」から。ルールがはっきりしているほど作りやすく、要件が複雑で更新が多いほど難しくなります。次の階段を下から上へ登るイメージで選びましょう。

1. 第1段：表・チェックリスト系（いちばんやさしい）
   進捗管理／年度更新タスク／書類チェック。情報を並べて色をつけるだけなので、最初の一歩に最適です。
2. 第2段：36協定チェッカー
   「月45時間・年360時間」など計算ルールが法律で決まっているため、判定の仕組みを作りやすい題材です。
3. 第3段：QAボット／FAQ
   就業規則などの資料をAIに読ませる一手間（＝RAG）が必要。少し準備は増えますが、効果も大きい段です。
4. 第4段：助成金マッチング（最後に）
   要件が複雑で更新が多く、間違いの影響も大きい。慣れてから、必ず人の確認とセットで取り組みます。

3部構成への当てはめ ― 36協定チェッカーの例

第2章で学んだ「フロント（画面）／バック（処理）／データベース（保管）」の3部構成に、実際のユースケースを当てはめてみましょう。どんなアプリも、この3つの役割に分けて考えられます。

作り方の選択肢 ― 用途で使い分ける

作る道具は1つではありません。手軽さと向き不向きで選びます。まずは（A）でその場に作らせてみるのが、いちばん早い入り口です。

プロンプト（AIへの指示文）の型

AIに上手に頼むコツは、申請書を書くときと同じ「型」を守ること。指示・入力・出力形式の3点セットで伝えると、ねらいどおりの結果が返ってきやすくなります。

作るのは「全自動の判断機」ではなく、「確実なダブルチェックの一段目」。それが事務所のAI活用の正しい入り口です。

むずかしい一発勝負ではありません。小さく作って、こまめに区切り、少しずつ良くしていく。社労士業務で日々やっている「下書き→ダブルチェック→清書→申請」とまったく同じリズムです。

通し手順 ― 1から6までを一気に見る

まずは全体の流れをつかみましょう。それぞれのステップは、これまでの章で学んだ道具とつながっています。

1. 手元でアプリを作ってもらう
   Claude Code（やCodex）に頼んでアプリを作り、localhost（自分のPCの中だけで動く画面）で動作確認します。中身は必ずダミーデータで。自分だけのお試し台なので、安心して何度でも試せます。
2. gitで区切りごとにコミット
   「ここまで動いた」という区切りでコミットし、履歴を残します。申請書の版を保存するのと同じ。あとで「前の状態に戻す」ができる安心の元です。
3. GitHubにpushして共有
   git pushでGitHub（コードと履歴を保管・共有する場所）に上げて仲間と共有。共同編集はブランチで別作業→PRで提案→レビューでチェック→マージで合流、の回覧フローで進めます。仲間にだけ見せたいときは非公開（プライベート）のリポジトリにできます。
4. Vercelと連携して本番公開
   Vercel（Webアプリを公開・ホスティングするサービス）をGitHubとつなぐと、pushするだけで自動で公開（自動デプロイ）。PRごとに出るプレビューURLで、マージ前に実際の画面を確認できます。
5. Neonにつないで本番データを保存
   本番のデータはNeon（クラウドのデータベース。中身はPostgreSQL）へ。接続文字列はコードに直接書かず、環境変数としてVercelに登録します。通信は暗号化（SSL／TLS）され、データへの読み書きは画面の裏側（バックエンド）経由にするのが基本です。秘密は鍵付き引き出しへ。
6. 改善のループを回す
   ブランチで直す→PR→マージ→自動デプロイ。この一周をくり返して、アプリを少しずつ育てます。完成ではなく「育てる」のが本番です。

横串の注意 ― いつも「どのデータを触っているか」を意識する

全ステップを通して大切なのは、いま自分が触っているデータはどこのものかを見失わないこと。場所を取り違えると、お試しのつもりが本番を壊す事故につながります。

改善のループ ― ここからが本番

公開はゴールではなくスタートです。使ってみて気づいた点を、小さな一周で直していきます。

「最初の一歩」チェックリスト

難しく考えず、今日できる小さな一歩から。下を上から順にこなせば、もう実践編はスタートしています。

• GitHub・Vercel・Neon にアカウント登録する（いずれも無料枠あり／2026年6月時点。最新は公式で確認）
• ダミーデータで「小さな画面」を1つだけ作ってみる
• 秘密（接続文字列・パスワード）は必ず環境変数に入れる
• 本物の個人情報は使わない（練習はあくまでダミーで）
• PRを1回出してみる（提案→レビュー→マージの流れを体験する）

小さく作って、こまめに公開し、何度でも直す。その一周一周が、未来の事務所を育てる。

これまでの章で学んだ知識を、いよいよ「事務所の意思決定」に変えていきます。大切なのは、全部を完璧に作ることではなく、賢く取捨選択することです。

まずはコスト感をつかむ

「Webサービスを作る・動かす」と聞くと、莫大な費用がかかると身構えてしまうかもしれません。実際には、学習段階や社内向けの小さなツールなら、ほとんど無料〜月数千円ではじめられます。規模が大きくなって初めて費用が育っていく、という感覚を持ってください。

内製か、外注か ― 線引きの考え方

すべてを自分たちで作る必要も、すべてを外注する必要もありません。「失敗してもダメージが小さく、自分たちで育てられるもの」は内製向き。「止まると重大で、責任が重いもの」は外注向き、と覚えてください。

生成AIの限界 ― 「自信満々の間違い」に注意

AIは強力な相棒ですが、万能ではありません。最大の弱点がハルシネーション（もっともらしいのに事実と違う、自信満々の誤り）です。コードを書かせると、一見正しそうでも欠陥が混ざることがあります。

※「29〜45%」はAI生成コードのセキュリティ分析に関する複数の調査で報告された幅、「約20%」は大規模調査（多数のAIモデル・約75万件規模）で「実在しないライブラリ」を提案した割合です。対象や時期で変動します（2026年6月時点）。

AIの出力は、人が確認するまでは「未確認の下書き」。

作って終わりではない ― 運用の4つの視点

サービスは公開してからが本番です。安心して使い続けるために、次の4点を最初から意識しておきましょう。

学習の次の一歩

もっと作れるようになりたい、と思ったら、まずは小さなAIツールやノーコードから始めるのがおすすめです。それぞれの違いを押さえておきましょう。

この「作る→使ってもらう→直す」の小さな繰り返しを、無理のない大きさで何度も回す。これが遠回りに見えて、いちばん確実な上達の道です。

DXは「共通言語」から ― 外注会話術

事務所のDXは、誰か一人の頑張りではなく、チームの共通理解で進みます。その土台になるのが用語集の共有です。経産省・IPAのデジタルスキル標準ver.2.0が、いわば全社員共通のOSのような役割を果たします。

• このツールは「内製向き」か「外注向き」か、線引きできているか
• 個人情報・お金・法的判断が絡む部分に、人の目とテストを通したか
• 認証（MFA）・バックアップ・障害時の段取りを決めたか
• 依頼するとき「目的」と「手段」を分けて伝えたか

完璧を一度に目指さない。小さく作り、確かめながら、賢く育てる。

専門用語は、知ってしまえばただの「業界の符丁」です。給与計算の等級や手続きの算定基礎届と同じで、一度覚えれば外部エンジニアやAIと同じ言葉で話せます。

基礎 ― Webアプリの土台

開発の場所と公開 ― 作る場所・出す場所

AIとデータ ― 道具と情報の置き場

バージョン管理とGitHub ― 版の記録と共有

安全と運用 ― 鍵と機密の扱い

1. 言葉を探す
   会話やAIへの指示で詰まったら、上の早見表で該当語をひと言確認する。
2. たとえで腹落ちさせる
   右側の「事務所の仕事でいうと」のたとえで、役割をざっくりつかむ。
3. 同じ言葉で相談する
   外部エンジニアやAIに、確認した語をそのまま使って質問する。

言葉が通じれば、相談できる。相談できれば、DXは独りで抱えなくてよくなる。

はじめての「あるある」をQ&Aで解消

つまずきは失敗ではなく、誰もが通る通過点です。原因がわかれば、もう怖くありません。実務で起きがちな順に並べました。

無料でどこまで? 主要サービスの早見表

「無料枠あり」と言っても、条件はサービスごとに違います。学習・試作と、お金をいただく商用利用の線引きを表で整理しました（2026年6月時点／最新は必ず公式で確認）。

外注で困らない「魔法の質問」チェックリスト

専門用語を全部覚える必要はありません。下の質問をそのまま投げかけるだけで、外部エンジニアと同じ言葉で話が通じ、認識のズレを防げます。打ち合わせや依頼メールにコピーして使ってください。

• 「これはlocalhostの話ですか? それとも公開済みですか?」——見えている画面がどちらかをはっきりさせる。
• 「データは本番のデータベース（Neon）に入りますか?」——消える仮データか、残る本番データかを確認する。
• 「変更は新しいブランチでPRにしてもらえますか?」——いきなり本番をさわらせず、回覧と承認印のステップを踏む。
• 「秘密情報は環境変数で扱っていますか?」——鍵がコードに直書きされていないかを確かめる。
• 「個人情報は匿名化／ダミーにしていますか?」——お客様の情報が安全に扱われているかを念押しする。
• 「AIが書いた部分は、人が確認しましたか?」——ハルシネーション任せにしていないかを確認する。

次の一歩——小さく、でも確実に

ここまで読んだあなたは、すでに「外注やAIと会話できる人」です。あとは小さく動いてみるだけ。次の3ステップを、肩の力を抜いてどうぞ。

1. 小さなアプリを1つ作る
   顧問先リストの簡単な一覧でも十分。完成より「作りきる体験」が宝物です。
2. PRを1回出してみる
   下書き（ブランチ）から回覧（PR）の流れを、自分の手で一度通してみる。怖さが「慣れ」に変わります。
3. ダミーデータで公開まで届かせる
   架空のデータで本番URLを発行し、同僚に送って「開けた!」を体験する。ここまで来れば一人前です。

わからないことは、恥ではなく出発点。同じ言葉で問えるようになった瞬間、あなたはもう「進められる人」です。