完成品ではなく、
作っている途中を書いている。

システム開発の世界に10年以上いる。だから自分が何をしたのか、その異常さがよくわかる。

最初に考えていたゲームのテーマは、製造業ではなかった。

システム開発でいちばん後から修正しにくい部分がある。データベースの設計だ。

開発には必ず「最初に動く瞬間」がある。

コードを書くより、ルールを決める方が難しかった。「現金がいくらになったら破産か」「DX投資の上限はいくらか」「市場需要は何個か」——これらは数字に見えて、本質は「どんな学びを生み出すか」という教育設計の問題だ。このプロセスで、3つのルールを

最初は線形だった。「競争スコアが2倍の企業は、シェアも2倍取れる」——これが最初のシェア配分ロジックだ。しかし、あるテストプレイで問題が発覚した。

数字には根拠が必要だ。DX変革に成功した企業の競争スコアが3倍になる——この3.0という数字は、1.5から始まり、2.0を試し、2.5を経て、3.0に落ち着いた。

ターンを進めるたびに何が起きるか。これを「処理の順番」として定義することが、ゲームエンジン設計の核心だ。順番が違えば、計算結果が変わる。最終的に9つのステップに整理した。

経営には「予期しない出来事」がある。好景気が来ることもあれば、原材料が高騰することもある。ゲームにこの「不確実性」を組み込むために、イベントシステムを設計した。

「このゲーム、DXに全振りすれば必ず勝てますよね」——テストプレイ後、参加者の一人にそう言われた。研修として失敗だ。ゲームの「最適解」が一つに収束してしまえば、多様な判断の面白さがなくなる。

ゲームを公開して数ヶ月が経ったある日、参加者からフィードバックが来た。「生産能力の上限が最初から決まっているのに、増やす手段がない。経営判断の幅が狭い気がする」——的を射た指摘だった。

数字を変えたら、ゲームのバランスが劇的に改善した話だ。

忘れられないテストゲームがある。6ターン目が終わったとき、画面に表示されたのは「全社破産」だった。4社全員が破産した。これは失敗だ。しかし、このゲームから多くを学んだ。

「このゲームはDX投資すれば必ず勝てるんですよね」という言葉を、研修の依頼を検討している企業の担当者から聞いた。この問いに答えることが、ゲームデザインの哲学を伝える機会になった。

2026年5月31日、午前9時8分。スマートフォンにGitHub Actionsからアラートが来た。「dxgame.jp — HTTP 200以外を検知」。その日、研修が予定されていた。

本番環境を更新するたびに、ある不安がある。「前の機能が壊れていないか」——機能を追加するとき、既存の動作に影響を与えることがある。直したつもりが別の場所を壊すことがある。これを手動で全部確認していたら、更新するたびに何時間もかかる。自動テス

「ステージングで動いたのに、本番で動かない」——これはシステム開発者が最も嫌いな状況の一つだ。この問題を防ぐために、ステージング環境と本番環境の「同一性管理」を徹底している。

夜中にサーバーが落ちていたとしても、誰も気づかない。研修の日の朝に「繋がらない」と連絡が来てから初めて知る——これが最悪のシナリオだ。

管理者画面に「緊急融資」ボタンがある。破産した会社に対して、政府救済として融資を実行する機能だ。破産しても研修が続けられる——これがこのボタンの存在理由だ。

ゲームの途中で、参加者が立ち止まることがある。「DX投資をいくら入れればいいのか、全然わからない」。ファシリテーターが1対1でアドバイスする時間は限られている。「AIを参加者の相談相手にしよう」と思った。

個人編が完成した後、「チーム編を作りたい」という要望が出た。複数人がチームとして1社を経営する——CEO・CFO・COO・CDO・CMOそれぞれが役割を持ち、提案し、議論し、最終的にCEOが決定する。要件を聞いたとき、正直「これは時間がかか

システムの変更は速い。ドキュメントの更新は遅い。これは多くのシステム開発プロジェクトで起きる問題だ。コードが変わっても、マニュアルや仕様書が追いつかない。DX経営ゲームも例外ではなかった。

システムが完成しても、売れなければ意味がない。最初の課題は「実績がないこと」だ。実績を作るために、無料のモニター体験会を企画した。

研修の価値を測るのは難しい。「楽しかった」「勉強になった」というアンケート回答は取れる。しかし「研修を受けた後、実際に何が変わったか」は、数ヶ月後にしか見えない。それでも、体験中の参加者の反応から、いくつかのことは言える。

このシリーズを書き終えて、DX経営ゲームの制作記を25本振り返った。設計の判断、失敗と修正、AIとの対話、本番障害、テスト自動化——全てのプロセスを記録した。最後に、次に作るものの話をしたい。

研修本番当日にリアルタイムでバグを修正し続けた記録。422エラー・スライダー上限・AI相談404・モーダル構造・alert()の5つ。

参加者の感想を具体的な実装案に落とし込む提言書の作成法。エンジニアでなくてもAIと協働できる翻訳スキル。

ターン番号固定の定型文から実際のゲーム状態に基づく動的インサイトへ。APIへの新フィールド追加と実装。

L1/L2/L3の進捗バーと閾値マーカーで変革への道を可視化。変革が起きない理由を直感的に把握できるUI。

全員共通のイベント説明から参加者のDX状態に基づく個別メッセージへ。イベントを運要素から経営判断の結果に変える。

4デバイスで44項目を自動検証。テーブルの実幅をJSで測定し崩れを自動判定する仕組みの構築。

min-width・nowrap・列数の多さによる崩れの原因と、CSSオーバーライド・ellipsis・列非表示の3解決策。

HTMLから削除したのにmanifest.jsonに残っていたicon参照。エラーの発信源を確認する習慣の重要性。

6戦略×140ゲームの結果。DX極振り1位率63%・破産率25%。攻撃的戦略は100%破産。データでバランスを証明。

7件の自動テスト失敗を調べたら、製品バグは0件だった。テストが正しくてもテスト自体が古ければ結果は嘘をつく。

Dropbox・EC2・手元と3箇所にファイルが存在する状況で、「正本」を定義してから検証を始めるルール。

comp-tableとhome-trend-tableのはみ出しをゼロにするまで。コンソールエラーと幅超過件数で合否を判定する。

製造原価報告書とキャッシュフロー計算書の実装。三帳票の整合性をどう検証するか。

採用フラグと従業員数の違い、スライダー上限の連動、費用計算、テスト境界値まで——1ボタンの裏にある連鎖。

固定テキストを動的表示に変えた。履歴APIにDX累積値を追加し、会社ごとに「なぜそうなったか」を表示する仕組み。

サプライチェーン攻撃のバグ修正と、条件連動イベントの設計。「運が悪かった」を言わせない仕組み。

GPT-4o-miniに現在の経営状態を渡しつつ、最終判断は参加者に残す設計。ルール早見表との役割分担。

参加者画面・仕様書・設計書・マニュアル・テスト仕様の5文書を横断照合した話。整合は一度では終わらない。

全員が提出しなくても進行できるフォールバックと、誤操作を取り消せる巻き戻し機能を同時に実装した。

検証役に立てた別のAIに、要件の文書と実物を突き合わせてもらった。返ってきた判定は受入不可だった。理由を読んで、私はしばらく画面を見たまま動けなかった。指摘は不具合の話ではない。作りそのもの…

最初に書いた案を、私は全部捨てた。AIを使いこなした企業に称号を与える案。毎ターンAIの活用度を判定して有利不利を出す案。どれも会議では受けがよかったのに、実装しようとすると必ず同じ壁に当た…

自分で作ったゲームを、自分で一人で通しで遊んでみた。何度か回して気づいたことがある。変革にはまったく手を出さず、効率化だけを積んだ企業が勝ってしまう。しかも、そこそこ勝つのではなく、圧勝する…

七十六本の自動試験が全部通っていた。私はその数字を添えて、実装が完了したと報告した。検証役に立てた別のAIが同じ試験を独立に走らせ、同じく七十六本の合格を確認した。それでも判定は差し戻しだっ…

開催当日の朝八時。参加は四十社、六つの班に分ける。開始は夕方六時半。前夜までの総点検で、進行が止まる級の不具合は零件だった。私は肩の力を抜きかけていた。

記事を書いた。次に考えたのは「どこで売るか」だ。

「認証と決済」——Webサービス開発の中で最も面倒な2つの機能だ。ユーザー管理のミスはセキュリティ事故につながる。決済のミスは金銭トラブルになる。それだけに「外部サービスに任せる」という判断が多い。

本番でStripeの決済テストをしたとき、購入完了後に記事が読めなかった。Stripeのダッシュボードを見ると「422 Unprocessable Entity」というエラーが記録されていた。

システムが動いてもコンテンツがなければ売れない。技術の話より先に、「何をいくらで売るか」「何を無料にするか」という設計の話をする。

サービスは動いている。記事も入っている。Stripeの設定も終わった。あとは公開するだけだ——と思っていたが、公開直後からトラブルが続いた。

そう思っていた。.envのAPIキーを差し替えてサービスを再起動するだけだ。何も難しいことはない。

これが最悪の状態だ。ユーザーにとって理不尽で、対応に追われるのはこちらだ。サブスクリプション決済は単発購入より状態が多い。テストを重ねて、その複雑さを自分で確認した。

ネットワークの問題でリクエストが消えることがある。サーバーが再起動中だと受け取れない。Stripeの側で一時的な障害が起きることもある。「払ったのに読めない」はどれか一つが欠けるだけで起きる。

これだけのことに、7つの問題が隠れていた。解約機能は「簡単に見えて複雑」という代表的な機能だ。

後回しにしていた機能だ。メール送信コードが既に存在していた。それだけが理由だ。既存コードの再利用が設計の恩恵になった瞬間だった。

1cto.jpのデータベースにはまだ入っていない。ファイルとしては存在しているが、サイトから読めない。1本ずつ管理画面から入力するという選択肢もあったが、54本は現実的ではない。

先頭に`# タイトル`という行があり、そのあとに本文が続く。データベースには`title`と`summary`の2カラムがある。ファイルを読んでこの2つを取り出す処理が必要だった。

`Bad permissions. Try removing permissions for user: UNKNOWN\\UNKNOWN (Errno: 13 - Permission denied)`

「子どもが教室に着いたかどうか、毎回気になるんです」

どんなシステムにも、「経験者なら5秒で気づく罠」がある。GAS（Google Apps Script）とLINEの組み合わせには、それが1つある。知らなければ何時間でも詰まる。知っていれば回避に10分かからない。

「Sat Dec 30 1899 10:30:00 GMT+0900」

習い事教室のタブレットUIを作り始めて、すぐに気づいた。スマートフォン向けのUIをそのまま拡大しても、タブレットで使いやすいものにはならない。

「教室を増やしたいんですが、システムも新しく作らないといけませんか」

最初の入退室管理システムのUIは3教室を前提に作っていた。

最初の入退室管理システムのスプレッドシートは、記録用のログシートだった。

スプレッドシートを直接編集してもらう、という運用はしたくなかった。

「予約管理で1日のうち何時間使ってると思いますか」

設計中に、一度だけ変なアイデアが浮かんだ。「フォームに『あなたのLINE IDを入力してください』という欄を作る」という案だ。

予約システムを作ろうとして最初に悩んだのは、「予約枠をスプレッドシートでどう表現するか」だった。

「設定が終わったので、テストしてみてください」と伝えた。オーナーが予約フォームから試し予約を入れた。数秒後、スマートフォンにLINEの通知が来た。

「自分の写真を使いたくない」という人がいる。顔を出すことへの抵抗感は、コーチやコンサルタントの仕事をしている人でも珍しくない。

リリースから数週間後、オーナーから連絡が来た。「コーチングのセッションも、同じ予約フォームで受けられるようにしたい」という要望だった。

「予約した後、Googleカレンダーにも入れられると便利」というフィードバックをオーナーからもらった。確かにそうだ。LINEで通知が来ても、それだけではカレンダーに予定が入らない。

オーナー通知のLINEを確認してもらったとき、オーナーからメッセージが来た。

「キャンセルが多くて困っている」という話を聞いたのは、予約システムを公開して少し経った頃だった。予約は来る。しかし当日になって連絡なしでキャンセルになることがある。

「予約、すごく使いやすかったです。予約と同時に案内が届くのも安心感がありました」

「振込先ってどこでしたっけ」という問い合わせが来た。

予約ID、サービスID、サービス名、枠ID、日付、時刻、氏名、電話番号、メールアドレス、LINE UID、ステータス、備考、作成日時。整理されているように見えて、一つだけ足りない情報があった。お金を受け取ったかどうかだ。

「このページのBefore/Afterコンテンツを反映させてほしい」

LPを見直したとき、「予約する」へのリンクが11箇所あることに気づいた。

「訪問の場合、交通費が確定しないと金額をお伝えできないんです」

「予約に失敗しました。時間をおいて再度お試しください。」

前日リマインドメッセージに「Sat Dec 30 1899」という文字列が入っていた。

バグが報告されたとき、自分でコードを読んで原因を特定した。修正した。動くことを確認した。

「オンラインレッスンのZoom URLを、予約確認LINEに自動で入れられませんか」

「体験セミナーや講座をイベントとして管理したい。定員があって、満員になったら受付を止めたい」

予約が入る。お客様が銀行振込をする。オーナーが通帳を確認する。スプレッドシートを開いて「支払済」と手入力する。お客様に「ご入金確認しました」とLINEを送る。

イベント管理機能をデプロイした直後、イベントが1件も返ってこなかった。

Codexがブラウザで `/reserve?type=event` を開いた。

管理画面のスクリーンショットが届いた。イベントの編集画面。日付、時間、所要時間、イベント名、説明、定員、参加費、決済URL、Zoom URL、アンケートURL。入力欄が縦にずらりと並んでいる。

スマホのメニューを作った。右上のハンバーガーを押すと、右からメニューが滑り込む。コンセプト、片づけ、コーチング、プロフィール。上に「×」の閉じるボタン。標準的なやつだ。

検索対策をしてほしい、と頼まれた。SEO。それと、AIO。

自分の書いたコードに、別のAIを当てた。Codexにセキュリティ監査をさせる。リリース前の、最後の確認のつもりだった。

ADMIN_PASSWORD = os.getenv("TTT_ADMIN_PASSWORD", "toitoi2024admin") GAS_ADMIN_SECRET = os.getenv("GAS_ADMIN_SECRET", "ttt-gas-admin-2024-secret")

「講師が一人ひとりの計画書を丁寧に見る時間は限られています」

Geminiは確かにレポートを返してきた。整った文章で、項目ごとに分かれていた。文字数は800字ほどだった。

受講者からの連絡だった。「添削レポートが2通届きました」。

別の市の創業塾からの依頼が来たとき、まずA版のコードを開いた。

そう連絡が来たとき、最初にやったのはコードのコピーだった。AiReview.gsを丸ごとコピーして、設定値3か所を書き換えた。AiReview_B.gsの完成だ。

GASは30秒でタイムアウトする。TypeFormは30秒以内にHTTP 200が返ってこないとWebhookをリトライする。Geminiは事業計画書の添削に1〜3分かかることがある。

添削フォームを送信したユーザーに、同じ添削レポートが2通届いた。1通は想定内、2通は不具合だ。Queueシートを見ると、同じevent_idの行が2件存在していた。2行ともDONEになっていた。

その店はそういう焼き菓子店だ。その市で手作りのタルトと焼き菓子を、完全予約制で販売している。注文は日曜の0時から木曜の12時まで。それ以外の時間は受け付けない。週に一度だけ開く扉を守るためのルールだ。

Instagramで告知を読む、ということも一つだ。しかしそれはお客さんが自分で確認しなければならない。システムならば、確認するまでもなく「今は注文できません」と表示できる。焼き菓子店のシステムが実現すべき最も重要なことがここにあった。

「商品写真も管理画面から登録できるようにしたい」というリクエストが来た。

スマホで管理画面が見やすくなっているはずだった。

「注文が届いたときのメッセージに、管理画面へのリンクを埋め込んでほしい」とオーナーから言われた。

「確定ボタンを押しても何も起きない」という連絡が来た。

言葉の発達がゆっくりだった息子さんが、「もう一個食べたい」という気持ちを人差し指を立てて「じっじ」と一生懸命伝えたことから、その名前がついた。また食べたいと思ってもらえるお菓子を届けたい、という意味を込めて。

週の7日のうち、52時間だけ注文を受け付ける。

デザインの打ち合わせのとき、洋菓子店のオーナーから見せてもらった写真がある。

洋菓子店の注文通知には、もともと管理画面のURLが文字列で入っていた。

洋菓子店の管理画面の不具合を直す前に、焼き菓子店で同じ問題に遭遇していた。

洋菓子店の管理画面はスマホから使うことを想定していなかった。

「ある大学の先生が実験データを出してくれたんです」

Formspreeはフォームのaction属性に専用URLを設定するだけでメールが届くサービスだ。設定は簡単だ。その施工会社のウェブサイトを最初に作ったとき、とりあえずFormspreeで動かした。

スプレッドシートに「jdnskndskjn」という名前の問い合わせが届いた。

「この車種、どこからフィルター取り出すんでしたっけ」

地域のお店を紹介する記事を1本作るのに、何時間かかるか。

この一文をプロンプトに入れるまで、Geminiは嘘をついた。

記事ができた。確認した。さて、どこに出すか。

AiInterviewは、LINEの会話を通じてAIがインタビューし、その内容を記事にするシステムだ。地域のお店や事業者をインタビューして、地域メディアに掲載する記事を自動生成する。

インタビューの途中で、ユーザーが短すぎる回答を返すことがある。

管理者は管理画面を開いたまま、インタビューが終わるのを待っている。

その言葉から始まった。店舗の防犯と来店マーケティングを目的とした顔認証SaaSを、シンプルシステム株式会社の自社プロダクトとして作ることにした。

422 Unprocessable Entity。

FastAPIの認証処理がpasslibで書いてある。ログインしようとすると失敗する。ライブラリのバージョン問題だった。passlibとbcryptの最新版の間に、互換性の問題が起きていた。

「Coolな感じで。テーマカラーは赤・黒・白」

ギャラリーに並べた絵をクリックすると、暗い背景の上に作品が大きく開く。ライトボックスというやつだ。コードは書いた。動くはずだった。

画家のサイトに、これまでの個展のチラシを並べたい。送られてきたのは六枚の画像だった。

サイトはできた。あとは公開するだけだ。`example-gallery.jp` を、自分のEC2に向ける。

Aレコードが新しいサーバーを指した。次はHTTPSだ。`https://example-gallery.jp` を、鍵のかかったアドレスにする。

中小企業の社長さんと話していて、「うちもAIを導入したいんですよ」と言われたことは、実はほとんどない。

無料診断を作っていて、いちばん悩んだのは「どこまで無料で出すか」だった。

人は、一度にたくさんのことを決められない。

最初に作った有料商品は、九千八百円の「AI実行プラン」だった。

AIを使った診断サービスを作っていて、いちばん最後まで気を抜けなかったのは、数字だった。

無料診断は動いていた。三分で「あなたの会社の業務は、AIや自動化に向いているか」をざっくり返す入口をつくり、その先に詳細診断を置いた。業務量や所要時間を入れてもらえば、現在の工数、効果の見込み、最初に試すべき一件、検証のやり方まで出る。さらにその先には、稟議に使える有料の設計書を生成する仕組みまで組んだ。

頭の中にある判断を、製品の側に移す。言うのは簡単だが、いざやろうとすると、自分が何を基準に決めているのかが、まるで言葉になっていないことに気づいた。

いちばん勇気がいったのは、品質チェックの扱いだった。

この再設計で、自分でも意外だった決断がある。無料相談をやめたことだ。

第2部を通してやってきたことを、最後に一つの問いにまとめておきたい。

無人ファネルを作ると決めて、まず自分の診断の入口を、もう一度開いてみた。

診断のフォームを作っていて、ずっと迷っていた一点があった。メールアドレスを、どこで訊くか、だ。

ある相手から、こう訊かれたことがある。「うちの注文書で、本当に動くんですか」。

ある問い合わせを見て、背筋が少し冷えたことがある。

無料相談をやめると決めたのは、第2部で書いたとおりだ。ただ、決めることと、入口から外しきることの間には、まだ距離があった。

成果物を自動で作る仕組みを組んでいて、一番神経を使ったのは、AIにどこまでやらせるか、という線引きだった。

成果物が形になってきた頃、自分でそれを読み返していて、ふと不安になった。

前の回で、適合判定の話の最後に、版を固定する、と書いた。今回はその中身だ。

自動化を進めるほど、逆に「ここはAIに任せない」という線を、はっきり引く必要が出てきた。

技術の堀、と大げさに書いてきた。けれど正直に言えば、その堀の多くは、新しく掘ったものではない。

集客を増やす前に、何から作るべきかを、紙に書き出した夜があった。

自分で作った仕組みに、わざと攻撃を仕掛けてみたことがある。

一件の支払いなのに、システムには二つの通知が来た。あやうく、同じ成果物を二つ作り、二重に請求しかけた。決済の世界では、こういうことが普通に起きる、と後で知った。通知は、一回だけ来るとは限らない。その前提が、私には抜けていた。

ある時、自分でも見落としていたことに気づいた。始め方ばかり作って、終わり方を作っていなかった。

無人化を進めても、消えないものがあった。例外だ。

最終部を書くにあたって、もう一度、あの計算をした。契約が一件増えると、自分の時間が何分増えるか。

売上を分解していて、ある弱点に気づいた。単発で、終わっていた。

売上のグラフを眺めていて、あることに気づいた。この数字を見ても、肝心なことが分からない。

設計書には、たくさんの業務が並んでいた。注文処理。問い合わせ対応。報告書作成。日報整理。どれも、自動化できる。

第1部のあの夜から、ずいぶん長く書いてきた。最後に、ここまでの全部を、一度ふり返っておきたい。

旗艦シリーズを一区切りにしたあと、私は電卓ではなく、広告の管理画面を見つめていた。表示回数は、九百ほど。クリックは、三十数回。そして、申し込みは、ゼロだった。

広告を止めたあと、私は自分と同じ領域の会社の広告を、片っ端から開いていった。相手がどう売っているのかを、見ておきたかった。その中に、手が止まる一枚があった。

私の診断の入口には、ずっと「AI内製」という言葉が、いちばん大きく置いてあった。自社の仕組みを、外注しきりにせず、AIを使って自分たちで作り直す。事業の核を、そのまま見出しにしていた。それを、外すことにした。

支援機関の相談の場で、私は何度も、同じ言葉を聞いてきた。業種が違っても、規模が違っても、経営者の口から出てくるのは、だいたい同じだった。「あの人が辞めたら、あの仕事は、もう誰も分からない」。

一度、広告で手ひどく外した。だから今度は、「これはいい痛みだ」と思い込む前に、公的な数字を、机の上に並べてみた。感覚のいい話ほど、数字で裏を取る。その順番を、守ることにした。

4社の取引先から、それぞれまったく違う書式で。月間カレンダー形式、着日指定のグリッド形式、店舗別混在形式、丸印で数量を示す形式。担当者は4種類の帳票を読み解いて、1行ずつ手でシステムに入力する。

FAX1枚が「注文書」であり、その中に複数の「明細行」がある。

4社の本物の帳票をClaude Vision（claude-opus-4-8）に読み取らせて、結果を確認した。「精度は帳票によって大きく違う」という予想は当たっていた。どの帳票が得意で、どこで失敗するか。実験の記録を残す。

「正しく読めているか見る」作業と「間違いを直す」作業だ。この2つは性格が違う。前者は速くできる。目でざっと追って「OK」を押せばいい。後者は集中が必要だ。元の帳票画像を見て、数値を確認して、修正する。

1枚目にカレンダー表、2枚目に備考、3枚目に追記。こういう帳票を「まとめて1つの注文として処理したい」という要件は当然だ。1枚ずつ別の注文として登録して後からまとめる、という操作は担当者には頼めない。

既存のEC2インスタンス（35.77.63.190）にはDXゲーム、予約システム、入退室管理システムなど複数のサービスが動いている。本システムも同じインスタンスに追加する。インフラコストをゼロで増やしながら本番環境を作る、というのがこのシステムの制約だった。

FAX帳票の読取精度を100%にすることはできない。

ある朝、予約システムを使ってくれている方から連絡が来た。「イベントが、全部消えています」。

「長い感想を入れると、保存できないんです」。

自分の作ったシステムに、わざと外から触ってみたことがある。

「直したはずなのに、変わらないんですけど」。

スマホ用に、画面の横から出てくるメニューを作った。開くアニメーションも、項目の並びも、閉じるための×印も、思った通りに表示されている。なのに、その×が押せない。タップしても、何も起きない。閉じられないメニューほど、間抜けなものはない。

四百件の出荷データを、一括で別の形式に変換する。そういう処理を動かした朝だった。件数も多いし、手作業では追いつかない。だから自動でやる。動かして、出てきたファイルを開いて、血の気が引いた。

出荷伝票を自動で作る処理を組んでいた。注文のデータから、宛先や品名を伝票の形に並べ替えて出す。出てきた伝票を、指定のフォーマットに通そうとしたら、弾かれた。

予約ページに、二つの入口を作っていた。ひとつは通常の予約、もうひとつはイベントの予約。同じページを使い回し、リンクに「これはイベント用」という合図を一つ付けて、開いたときに切り替える。そういう仕組みだった。

「確認のメールが、二通来ました」。お客様からそう言われて、記録を見た。たしかに、まったく同じ申込が、ほんの一秒ほどの差で、二件並んでいた。

受け取り希望の時間を、お客様に選んでもらう。「13:00」とか「16:30」とか。それを表計算シートに記録して、あとで通知に載せる。単純な話のはずだった。

長く続いてきた地域の情報紙がある。町のできごと、店の話題、暮らしの知らせを、紙で届けてきた媒体だ。その会社から、Webサイトを新しくしたい、と相談を受けた。

サイトの中身が決まると、次は動かす仕組みだ。記事を出すAPI、広告を受け付ける入口、投稿された画像の置き場。役割で数えると、けっこうな数になる。

広告主が、自分で広告を投稿できる。この入口を作るとき、いちばん時間をかけたのは、投稿された広告を「すぐには載せない」仕組みだった。

管理画面のログインは、あっさり動いていた。パスワードを入れると入れて、しばらく操作でき、時間が経つと切れる。試したときは、何の問題もなかった。

サイトが動きはじめてから、編集部の仕事を軽くするために、AIをいくつか組み込んだ。数えると、八つになった。派手な一つの機能ではなく、日々の作業のあちこちに、小さく差し込んでいった。

ある食品の卸に、社内で使うシステムを作ることになった。注文は、いまも電話で来る。年末になると、朝から鳴りっぱなしになるという。受けた注文を紙に書き、あとでまとめ直し、出荷の指示に回す。この流れが、繁忙期に人を疲れさせていた。

録音を文字にするところまでは、すぐ動いた。問題は、その文字を、注文として使える形に直すところだった。

電話の録音から、注文が自動で立ち上がる。ここまで来ると、いっそ出荷まで一気に流したくなる。人の手を、一つも介さずに。

注文の取り込みと並んで、もう一つ頼まれたのが、出庫の記録だった。倉庫から品を出すとき、何を、いくつ出したかを残したい。これまでは、伝票を見ながら手で書き写していた。

ある支援機関から相談を受けた。担当者が、地域の事業者を回り、経営やデジタル化の相談に乗る。その記録が、長年にわたって溜まっている。日付、事業者、相談の内容、使った道具、解決したかどうか。膨大な現場の知恵だ。

条件から相談履歴を引けるようにすると、次の壁が見えてきた。その条件を、誰が入力するのか、という問題だ。

素材からAIに項目を起こさせる機能は、短い音声や小さな画像では、気持ちよく動いた。提出すると、すぐに欄が埋まる。うまくいった、と思った。

あるネット販売の事業者から相談を受けた。注文は販売サイトに溜まる。発送は配送会社の仕組みに入れる。この二つが、つながっていない。

変換ツールが動きはじめてすぐ、報告が来た。「電話番号の、先頭のゼロが消えています」。注文番号も、桁が足りない。せっかく変換したのに、肝心の番号が壊れている、という。

帰りの翻訳機、つまり追跡番号を販売サイトの側へ書き戻す道具を作るとき、最初は素直に組んだ。何列目に注文番号があり、何列目に追跡番号がある、と位置で決め打ちして、そこへ書き込む。

帰りの翻訳機を、いろいろな形のデータで試していた。見出しの名前で列を探す作りにしたので、多少の違いは吸収できる。ほとんどの形で、追跡番号は正しく書き戻せた。

ある習い事教室の、入退室のお知らせの仕組みを、数年前に作った。子どもが教室に着くと、タブレットで名前を押す。すると家族のスマホに、着きましたと届く。帰りも同じ。小さな仕組みだが、毎日使われている。

引っ越しを始めるとき、自分に一つ縛りをかけた。使う人が触る画面は、一つも変えない。タブレットも、管理画面も、家族に届くお知らせも、これまで通り。変えるのは、その裏でデータを出し入れしている部分だけにする。

引っ越しで、いちばん気を遣ったのが、ログインのパスワードだった。教室のオーナーは、それぞれ自分のパスワードで管理画面に入る。裏側を入れ替えたとき、そのパスワードが使えなくなったら、全員に作り直してもらうことになる。

この仕組みでは、家族が使うメッセージアプリを通じて、二つのことをしている。一つは、着きました・終わりました、というお知らせを送ること。もう一つは、家族からの登録や停止の連絡を、受け取ることだ。

引っ越しが終わって、一つ、はっきりと変わったことがある。これまでデータは、クラウドの表計算にあった。オーナーも中を見られたし、いざとなればそこに残っていた。引っ越し後、データは、自分たちのサーバーの中の、一つのファイルにまとまった。

ある施工サービスの会社から、SNSでの発信を増やしたいという相談を受けた。伝えたいことは二つある。一つは、施工を頼みたい人に向けた案内。もう一つは、一緒に施工を担ってくれる仲間の店を増やす募集だ。どちらの投稿も、その先には公式のメッセージアプリやサイトの窓口が待っている。

下書きを自動で作る仕組みはできた。次に決めるのは、その下書きを誰が世に出すかだ。技術的には、生成から投稿まで人を挟まず全自動にできる。実際、最初はそのつもりで作り始めた。けれど途中で立ち止まり、一か所だけ人を残すことにした。投稿する直前の、承認だ。

SNSでは、静止画より短い動画のほうが人に届きやすい、と言われている。ただ、動画には撮影という壁がある。現場は毎日忙しく、撮影を頼める体制はない。手元にあるのは、施工の前と後の写真と、現場の写真が数枚だけ。

承認画面には、動画をその場で作り直すボタンを付けてあった。ある日、それを押すと、しばらく待たされた末にエラー画面が出た。時間切れ、という素っ気ない表示。何度押しても同じだった。

投稿が自動で続くようになると、次の関心は、どの投稿が効いているのかに移る。感触で語ることはできる。けれど感触は、たまたま目にした一件に引きずられる。数字で見たかった。一人で回している仕組みだからこそ、判断の根拠は、自分の感覚の外に置いておきたい。

ある観光地の、有名な名所のすぐそばに、小さなギャラリーがある。色彩を専門にしてきた店主が、絵画や工芸品を展示して売る店だ。サイトはすでにあった。既製のホームページ作成サービスで作られたもので、店の紹介としてはよくできている。ただ、そこには売り場がなかった。作品を気に入った人が、その場で買う手段がないのだ。

七月の頭、デザインを大きく作り替えた版を見せた日のことだ。世界的に有名なギャラリーのサイトを手本に、余白をたっぷり取り、色をほとんど消した、真っ白でミニマルな画面。我ながら垢抜けたと思っていた。返ってきた言葉は短かった。冷たい、いまいち。その日のうちに撤回した。

サイトの公開から一週間ほどたったころ、作りを左右する話がひとつ決まった。このサイトは、将来、いまのクラウドから格安のレンタルサーバーへ引っ越す可能性があるという。ならば、特定のサーバーの機能に寄りかかった作りにはできない。そしてもう一つ。作品の入れ替えや展示の告知は、制作側を経由せず、店主が自分の手でできるようにしたい。頼まれるたびに私が動くのでは、更新はいつも後回しになる。この二つを同時に満たす方法を考えた。

一度、作品一覧のカードを、美術館のラベル風に作り替えたことがある。中央寄せで作品名と作家名だけを静かに置き、価格は小さく、カートに入れる、の文字は控えめなテキストに。売り場の気配をあえて薄めて、展示室の空気に寄せた。ギャラリーなのだから、売り込みがましくない方が上品だろう、という判断だった。だが、それは作り手の思い込みでもあった。

ある地域情報紙から、相談を受けた。サイトに載せた新着記事を、メッセージアプリの公式アカウントにも流したい。読者が毎日サイトを見に来てくれるとは限らない。向こうから届けば、読まれる機会は増える。ただし、いま動いているサイトには手を入れたくない、という条件付きだった。長年動いてきたサイトである。触らずに済むなら、それに越したことはない。この制作記は、その配信の仕組みを設計し、作り、動かすまでの記録だ。

仕組みの骨組みができて、試運転を始めた。実際には送信せず、取得と整形だけを試す空振りの運転で、まず対象の記事が正しく拾えるかを確かめる。対象は、サイトの区分でいう記事・告知・求人・連載・特集の五つ。伝言板だけは除く取り決めだ。ところが、記事の分類で絞り込んで取得すると、返ってくるのが0件。サイトには今日も新しい記事が並んでいるのに、である。

新着を拾い、カード型のメッセージに整え、自動で配信する。そこまで動くようになった稼働の直前で、立ち止まった。本当に、拾ったものを無条件に送っていいのか。相手は情報紙の公式アカウントで、届いた瞬間に読者のスマホが鳴る。間違いは取り消せない。完成間際の方針転換にはためらいもあったが、確認と承認を挟んでから配信する形に変えると決めた。あわせて、送る記事の種別を選べるようにしてほしい、という要望にも応えることにした。

本番稼働からしばらくして、クライアントから動作確認の報告が届いた。丁寧に試してくれた形跡のある、具体的な報告だった。不具合が二件、要望が一件、それに気になる点が一つ。作った側の試験では見えなかったものが、使う側の目には最初の数日で見えている。ありがたい報告である。一つずつ応えていった。

2026年、私はパソコンの画面の中でプラモデルを組んでいた。マウスでパーツをつまみ、所定の位置まで運ぶと、カチッと音がして嵌まる。左には設計図があり、いま組むべき工程の番号が金色に光る。起動すると、箱を開ける演出まで付いている。誰かに売るものではなく、思いつきを形にしただけの試作品だ。それでも、画面の中で模型が組み上がっていく感触には、妙な手応えがあった。

権利フリーの方針を決めたあと、要件定義を書いた。軸に据えたのは「難易度はパーツの数で作る」という一行だ。試作の画面で百個近いパーツを眺めながら考えていた。初めての人にこの数は多すぎるし、慣れた人に十個では物足りない。同じ題材を、易しくも難しくも遊べるようにしたい。

遊びの骨格は通った。難易度も、コレクションも、壁紙も動く。それでも、触るほどに一つの引っかかりが育っていた。これは模型というより、平面のパズルに見えるのではないか。絵合わせと模型の間には、埋めがたい溝がある。平面のまま、どれだけ見た目を磨いても、その溝は越えられない気がした。思い切って、本物の立体に踏み込むことにした。

立体になったのは良かったが、まだ玩具に見える。「実物そのものと見紛うくらいでないと、売り物にはならない」。そう突きつけられて、私はしばらく描画の設定をいじり続けた。光の当て方、影の濃さ、映り込み。数字を細かく詰めれば詰めるほど本物に近づくはずだと、そう思い込んでいた。だが、いくら詰めても、玩具は玩具のままだった。

ここまでは、こちらが用意した題材を組む話だった。最後に、この試作でいちばん賭けている構想を書く。使う人自身の写真から、その人だけの模型を作る。棚に飾った思い出の品でも、可愛がっている乗り物でも、自分の手元にあるものが、画面の中で組み立てられるキットに変わる。目指しているのは、そういう遊びだ。

ある在宅訪問の管理栄養士から、サイトに栄養コラムを載せたい、と相談を受けた。作って終わりではなく、これから先、本人が思い立ったときに自分で書き足していける形にしたい。小さな事務所だ。維持費は極力かけたくない。この二つの条件が、作りの前提を最初から決めていた。ブログという、ありふれた機能を、どれだけ身軽に持てるか。そこが勝負だった。

データベースを使わないと決めたあと、次の問いは「見せ方」だった。記事を毎回その場で組み立てて返す作りにすると、閲覧のたびにサーバーが働く。安い器では、それが遅さや不安定につながりやすい。訪問の合間にスマホでコラムを開く人に、待たせたくはない。そこで選んだのが、書いた瞬間に、表示用のページをあらかじめ作り置きしておく方式だった。

安い器で始めたが、事業が育てば、いずれ上位のサーバーへ移りたくなるかもしれない。そのとき、いまの作りが特定のサーバーの機能に根を張っていると、引っ越しは難儀する。だから最初から、どこへでも持っていける身軽さを設計に織り込んだ。あわせて、管理画面の入り口である認証も、外の仕組みに頼らず自前で用意した。この二つは、別々のようでいて、同じ「縛られない」という一本の方針から出ている。

ブログで一番気を遣ったのは、写真の扱いだった。栄養コラムなら、料理や食材の写真が主役になる。記事の頭に大きく一枚、本文の途中にも何枚か。書く人が迷わず差し込めて、なおかつ、危ない使われ方をしない。この二つを同時に満たすのが、思いのほか難しい。手軽さに寄せれば穴が空き、守りに寄せれば使いにくくなる。その綱引きの記録だ。

小さな個人サロンの経営者から、お店のウェブページを作ってほしいという相談を受けた。話を聞くと、最初は無料のサイト作成の道具を使って自分で組もうとしたが、思うようにならず、それなら任せたい、というかたちで来た。要望は三つあった。地図と、メニューの一覧と、雰囲気の分かる写真を載せたい。予約はすでに公式のメッセージアプリを使っているから、それはそのまま活かしたい。予算はあまりかけたくない。

ページの中身が形になってきたところで、写真の扱いに手をつけた。経営者から受け取った写真は、店内の様子と、施術の場面と、使っている道具の三種類、合わせて数枚あった。これを、ページの一部として、そのまま並べたい。ふつうなら、写真はページとは別のファイルとして持ち、ページを開いた側の機械が、写真を後から取りに来る。その取りに来る回数を、できるだけ減らしたかった。

一枚のページが形になった。あとは、このページを誰にどうやって見つけてもらうか、を考える段になった。地域の小さな個人サロンでは、検索の結果で目立つ位置を取るのは難しい。強い会社が上に並んでいて、そのすぐ下に個人の店が食い込むのは、なかなか厄介だ。ならば、検索の結果に入り込めなかった人にも、店にたどり着いてもらう道を、いくつか作っておこうと考えた。

お店のページには、SNSの最新の投稿をそのまま表示するかどうか、いつも悩ましい問いがある。開いた人に「今も生きているお店だ」と伝わりやすいし、更新の手間もない。ただ、その気軽さの裏には、いくつかの割に合わない負担が隠れていた。今回のお店では、生きた埋め込みをあえてやめて、静かな写真を三枚だけ置く形にした。

画面いっぱいに、通過の文字が並んだ。二十八件、失敗ゼロ。利用者が画像を送り、AIが立体のデータを組み立て、手元に届くまでの道筋が、ひととおり動いた。それでも、公開の手を止めた。動くことは確かめた。けれど、動かなかったときにどうなるかを、まだ何も確かめていなかった。

仕上がった一件ぶんの記録を眺めていた。どの画像を材料にしたか、どの道具のどの版で組み立てたか、途中でどんな判定を通ったか、出来上がったものの指紋はどれか。ここまで残っていれば、後から何を聞かれても答えられる。問題は、この記録が、その気になれば書き換えられることだった。

昨日まで動いていた組み立て処理が、ある朝、立ち上がらなくなった。設定は変えていない。書いたコードも触っていない。調べていくと、土台にしている読み込み用の部品が、新しい系統に上がっていた。新しい系統では、モデルの内部構造の呼び名が変わっていて、こちらが触ろうとしていた層が、そもそも存在しなくなっていた。

公開の日取りを決めたとき、機能の一覧を眺めて、一つだけ線を引いて外した。出来上がっている、試験も通っている、けれど公開初日には動かさないと決めたものがあった。作った成果物をそのままSNSへ流す仕組みだった。

公開の準備で最後に残ったのは、自分しか使わない画面だった。注文の状態を見たり、公開してよいものを選んだりする管理の画面が、利用者向けのサイトと同じ入口にぶら下がっていた。認証はかけてある。それでも、住所さえ分かれば、誰でもそのログイン画面までは辿り着ける状態だった。

提案の資料は一式そろっていた。企画提案書、システム要件定義書、概算見積、それらを束ねた統合資料。地域の商工団体へ出す、まちぐるみのスタンプラリーの提案だった。参加する店はおよそ百二十。真冬の…

店にお願いするのは掲示物を貼ることだけ、と決めた瞬間に、難しい問題が一つ残った。貼ってあるだけの札は、誰でも撮れる。撮った写真は、そのまま人に送れる。店に行かずに印が入る道が、設計上いちばん…

店頭に貼る掲示物を四十枚ぶん出力した。A5の紙面に店の名前と遊び方を載せ、真ん中に符号を置いた形だ。出したあと、念のために画像から符号を読み直して確かめた。四十枚中、三枚が読めなかった。画面…

札の写真が共有されうる、という残ってしまうリスクをそのまま抱えたまま、次に考えたのは見つけ方だった。完全には防げないのなら、起きたときに気づけて、気づいたあとに手を打てる形にしておくしかない…

一式ができたので、確かめる工程に入った。要件定義書に並べた受け入れ条件の番号を、そのまま試験にした。二十二項目。あわせて、実際のブラウザで四つの画面を通しで操作して回る検査も書いた。こちらは…

午前一時三十九分、私は「何をするか見るだけ」のつもりで一行を打った。作らない、上げない、公開しない。そういう印を付けたはずだった。ところがその回は、本当に公開された。予定は同じ日の朝七時で、…

私が書いた台本には、原典と逆のことが書いてあった。競争の型を扱った古典の回で、買い手が強くなる条件を、買い手にとっての購入金額が小さいとき、と説明していた。原典は逆で、買い手の費用に占める割…

読み上げに渡す台本には、読みを指定できる。表示はこの字、読みはこの音、と書き分ける仕組みだ。私は当初、数字は読み側を漢数字にする、という規則を作っていた。ある日、同じ文を九通り作って聞き比べ…

短い動画は縦、本編は横で作る。道具も別で、縦のほうは一つ走らせれば動画まで出来上がる。私はある日、時間を惜しんで手順を手で並べ、本編と同じ流れを縦の動画にも当てた。縦で出来たものの上に、横で…

語り手の絵柄を替えた。一日のうちに四回替わって、年齢相応の五代目に落ち着いた。問題はその後で、すでに公開した回をどうするかだった。私は、公開済みの本体は差し替えない、と決めた。

百年をゆうに超えて続く、街の小売店のウェブサイトを作り直すことになった。元のサイトは、書いてある事実そのものは正確だったが、体裁がひと昔前のままで、携帯電話で開くと文字が小さく、横に滑らせな…

この店には、四つの商売が同居している。酒。学校の制服と体育衣料。贈答品。そして健康食品。一つの店でありながら、扱っているものの系統がまるで違う。作り直しの前のサイトは、この四つが一枚のページ…

作り直しでいちばん危ないのは、見た目を整えるついでに、情報を整理してしまうことだと思っている。古いサイトは、たしかに読みにくい。文章が長く、注意書きが多く、否定形が並ぶ。だから新しくするとき…

このサイトには、買い物かごも決済もない。値段を並べた商品の一覧すらない。それなのに、特定商取引法に基づく表記のページは作った。矛盾しているように見えるが、そうではない。順序として、こちらのほ…