小さなスタジオのために予約サービスを作るとします。時間帯の選択、情報の入力、通知の送信、そして店主が予定を確認できる管理画面。必要な機能を AI に伝え、それらが少しずつ操作できる画面になっていくと、遠く感じられたプロダクトが形を現し始めます。
ところが、それを見た店主から返ってくるのは、こんな一言かもしれません。「お客さんが急に時間を変えたら、やっぱり三か所をそれぞれ直すんですか？」
この問いは、プロダクトを現場へ引き戻します。画面は動くようになっても、仕事が楽になったとは限りません。以下のスタジオは、考察のための架空の事例です。AI によって実装の一部が容易になったとき、プロダクトは自らの存在理由をどう説明し直すべきか。この例を通じて考えたいと思います。
コードが舞台裏へ退くとき、誰の注意が変わるのか
大多数のユーザーにとって、コードは以前から舞台裏にありました。関心があるのは、予約を完了できるか、情報を見つけられるか、用事を済ませられるかです。こうしたニーズは生成 AI よりも前からあり、ツールの更新だけで自動的に変わるものではありません。
新しい変化は、作り手の側で起きています。一部の作業では、以前は一段ずつコードへ翻訳する必要があった要求を、まず自然言語で伝え、実行結果や画面、フィードバックを通して修正できるようになりました。注意を向ける先も、一つひとつの書き方から、何を作るか、結果が期待に合っているか、どこに介入が必要かへ移る余地が生まれます。
私はこの移行を「AI がコードを覆う」と表現しています。覆われるのは実装過程の一部であり、その下のデータ構造、実行条件、エラーは残っています。結果が期待から外れたとき、作り手には問題がどの層にあるかを見極め、その抽象化の層を開いて調べる力が必要です。
ここには見落としやすい前提があります。何をもって完了とするか、自分でわかっていなければならないことです。「予約システムを作って」と言うのは簡単です。しかし、最後の一枠を二人が同時に予約したら何が起きるべきかを明らかにして、初めてプロダクトの境界に触れます。要件の空白は、結局、誰かの判断か何らかのシステムの挙動によって埋められます。
実装が速くなると、その空白も早く具体的な挙動になります。画面が完成しているほど、チームはデフォルトの選択を、すでに議論した決定だと思いやすくなります。使える成果を見たときこそ、どのルールが実際のニーズから来ていて、どのルールは生成の過程が代わりに決めたものなのか、振り返る意味があります。
作れるようになった後、違いはどこから生まれるのか
ある種類の機能を作りやすくなったなら、その機能を持つことで生まれる違いも見直す必要があります。予約フォーム、通知テンプレート、管理一覧はどれも便利です。しかし似た組み合わせが増えるほど、ユーザーが比較する理由も増えます。自分の仕事の流れに合うのはどれか。移行にはどれだけ手間がかかるか。問題が起きたとき、相談できる人はいるか。
私の見立てでは、AI は実装の難しさによって保たれてきた一部の違いに、より強い圧力をかけます。ただし、この見立てには範囲があります。説明しやすく、検証しやすく、成熟したパターンがある機能と、特殊なアルゴリズムや深い業務知識を必要とするシステムでは、条件が異なります。
プロダクトの価値は、もともとユーザーを起点に考えるべきものでした。変わるのは、資源を投入する理由です。機能を一つ追加するコストが下がると、チームは「ほかに何を加えられるか」と拡張を続けやすくなります。しかし、ユーザーが機能を理解し、ルールを設定し、データを移すコストまで下がるとは限りません。店主にとっては、選択肢が一つ増えることが、決めなければならないことを一つ増やす場合もあります。
だからこそ実装能力が高まると、取捨選択はより具体的になります。特定の種類のスタジオだけに対象を絞れるか。明快な流れのために、一見汎用的な機能の一部を手放せるか。作りやすくなるほど、追加するものが誰のどんな負担を減らすのかを確かめる必要があります。
METR は 2026 年の技術職向け調査で、作業の速さと成果が生む価値を意識的に区別し、自己申告による向上は客観的に検証された効果と同じではないと注意を促しています。この調査はどんなプロダクトが成功するかには答えていませんが、測定対象を区別する考え方は役立ちます。誰も必要としていない管理画面を速く完成させても、注意力を速く消費しただけかもしれません。
このことは、何を資産として積み重ねるべきかにも影響します。スタジオへの理解は、妥当な初期設定、適切な例外処理、導入しやすい仕事の流れへと育てられます。競合が画面をコピーしても、各選択の理由まで理解しているとは限りません。ただし、その理解も継続して現場と照らし合わせる必要があります。チーム内の想像だけになれば、それ自体が重荷になり得ます。
予約機能から、予約の成立へ
あのスタジオに戻りましょう。運営者は一人で、昼は接客し、夜にメッセージを返しているとします。顧客の要望はメッセージアプリ、カレンダー、紙の記録に散らばっています。運営者は確認の往復を減らしつつ、常連客や特別な要望には柔軟に対応したいと考えています。
フォームを送信できるページは、情報収集を解決します。しかし、予約を成立させるにはまだ多くの判断が必要です。サービスの前後に準備時間は必要か。顧客が選んだ枠はまだ空いているか。日程変更後、元の枠はいつ開放されるか。通知が届かなかったら、誰が未完了だと気づけるか。
こうした細部が、プロダクトの動作を変えます。カレンダーの同期に遅れがあるなら、古い情報だけを根拠に予約成功と伝えるべきではありません。特別な要望を運営者が確認する必要があるなら、画面は「申請を受け付けました」と「予約が確定しました」を明確に分ける必要があります。この二つの文言の間には、ユーザーがこれから出かけるべきかどうかという判断があります。
どの仕事を改善するかがわかると、位置づけが明確になり始めます。機能は引き続き重要ですが、約束と証拠につなげる必要があります。
| 機能 | ユーザーへの約束 | 検証の方法 |
|---|---|---|
| 時間帯の選択 | 実際にサービスを提供できる時間を選べる | 競合や二重予約を確認し、人手で修正する割合を追う |
| 日程変更 | 一度の変更で関連記録がそろう | 一回の変更に必要な操作数やメッセージの往復を観察する |
| 通知とリマインダー | 双方が現在の状態と次の行動を把握できる | 配信状況、状態の誤解、人手で補う通知の回数を確認する |
表には、見栄えのよい成果の数字を先に置いていません。実際に導入するときは元の仕事の流れを観察し、利用後との差を見て、設定、照合、修復にかかる時間も含めるべきです。返信を数件減らせても、AI の間違いを毎日確認する負担が増えたなら、節約した時間が別の形で戻ってくるかもしれません。
約束も、プロダクトが影響を与えられる範囲に収める必要があります。リマインダーは時間を思い出す助けにはなっても、全員の定刻到着を保証はできません。観察できる状態を明確に示し、確認待ちの予約を店主が早めに把握でき、連絡や調整の余地を残すほうが責任ある対応です。効果をどう正確に伝えるかは、ユーザーの期待に直接影響します。
現場の理解は、競争相手の捉え方も変えます。このサービスが競っている相手は、店主が使い慣れたメッセージアプリと紙のカレンダーの組み合わせかもしれません。新しいシステムは、今の習慣を変える価値があるほどよくなければなりません。機能が同じかどうかは、比較の一部分にすぎません。
仕事を任された後、画面は何を見せるべきか
店主が「金曜午後の予約を来週へ移して」と直接伝えられるようになると、プロダクトは仕事の委任を受け始めます。この一言は多くの操作と、多くの条件を省略しています。すべて移すのか。顧客は同意しているか。翌週に十分な空きはあるか。
よい操作体験は、そうした条件を判断できる画面へ戻します。システムはまず影響を受ける予約と利用可能な枠を示し、店主の確認後に顧客へ通知できます。すぐに調整できない項目には、明確な状態と人が引き継ぐ入口を残します。どこまで進んだかわかってこそ、安心して仕事を任せられます。
これはチャット欄の限界も示しています。自然言語は意図や背景を伝えるのに向いていますが、一週間の空きはカレンダーのほうが比べやすいことが多いでしょう。複数の日程変更の前後も、表にすると確認しやすくなります。タスクに応じて表現を切り替え、説明、比較、確認のそれぞれに合う場所を用意できます。
システムの判断材料も、確認できるべきです。例えば「午後は空いている」という情報は、最新の予定から来たのか、店主が先週言ったことなのか。推論過程をすべて見せる必要はありませんが、予定に影響する箇所では、照合できるデータと制約を示す必要があります。そうすればユーザーは、どの条件を直せば後続の処理を正しい方向へ戻せるかがわかります。
主導権には、考えを変えられることも含まれます。通知前に取り消せるか。送信後に訂正を送れるか。自動処理の範囲は明確か。こうした問いには、流れを設計する段階で答えるべきです。どこまで任せようと思えるかを左右するからです。
毎回確認し直さなければならないなら、委任の価値は失われます。一方、すべてが黙って完了すると、必要な判断の機会を失いかねません。プロダクトには、本当に立ち止まる価値がある節目を見つけ、それ以外の進捗も見えるようにする必要があります。これは状況に依存する設計の仕事であり、「自動化は多いほどよい」では置き換えられません。
見えないエンジニアリングが、体験を決める
簡潔な画面ほど、その下のシステムが負う責任は増えます。二人が同時に予約してもデータの整合性を保つ。通知を再試行しても、矛盾するメッセージを送らない。停止後に引き継ぐ人が、どの処理まで完了したかを把握できるようにする。
こうした仕事は紹介動画では見えにくくても、日常の利用で繰り返し信頼を左右します。とりわけプロダクトがユーザーに代わって実行する場合、誤りは画面の外へ出て、他人の予定に影響します。エンジニアリングの品質は、そのままプロダクトの約束の一部になります。
Anthropic の 2026 年の Managed Agents に関する技術記事は、永続的なイベント記録と実行環境を分離し、実行コンポーネントが失敗しても作業を再開できる設計を説明しています。この例は、操作を簡単にする裏側にも、状態の保存と障害復旧の仕組みが必要だと具体的に示しています。すべての予約サービスに同じ構成が必要だという意味ではありません。
エンジニアリング自体が、プロダクトの最も重要な違いになることもあります。極めて低い遅延、特殊なデータ処理、オフライン動作、再現しにくい連携などは、あるニーズを満たせるかどうかを直接決めます。あらゆるコードが安価な部品になると考えてしまうと、こうした具体的な制約を見落とします。
私が重視するのは、技術への投資が結果をどう改善するのか、チームが説明できるかです。このスタジオなら、生成メッセージの口調を増やすより、二重予約を確実に防ぐほうが先かもしれません。既知の仕事の流れは、毎回モデルに判断させるより固定ルールで処理するほうが適切な場合もあります。どこに AI が必要で、どこに確実性が必要かを知ること自体が、プロダクトを作る力です。
プロダクトの約束を書き直す
この架空のプロダクトを一文で紹介するなら、「AI スケジューリング、自動通知、スマート管理を備えた予約プラットフォーム」は機能を説明できます。しかし、自分の現状とどう関わるのかは、店主が推測しなければなりません。
私はもっと具体的に書いてみます。「独立したスタジオの予約と日程変更を一か所で扱い、確認の往復を減らし、判断が必要なところで運営者が引き継げるようにします。」これは証明済みの成果ではなく、設計と利用を通じて検証する約束です。対象を選び、何を優先すべきかをチームに伝えます。
範囲を絞ると、最初の一歩も検証しやすくなります。まず一人で運営するスタジオの一回の日程変更を最後まで整え、元の枠の開放、記録の更新、通知がつながることを確認してから、複数人のシフトを考えられます。この順序なら実際の利用から学べますし、機能数を問題理解の代わりにせずに済みます。
次に、四つの問いに答える必要があります。誰のために作り、その人は今どう仕事をしているのか。どの観察可能な結果を改善したいのか。改善が起きたことをどんな証拠で判断するのか。システムが対応できないとき、誰が引き継ぎ、どう修復するのか。
この四つは、機能を追加するたびに使える問いです。賢そうに見せるだけで、どの答えにも結びつかない機能なら、後回しにする価値があります。浮いた実装時間を、現場の観察、設定の簡素化、失敗時の体験づくりに使えます。
デザイナーと開発者の仕事も、より密接につながります。問題の定義には技術の境界の理解が必要で、技術の選択にはユーザーが求める結果を知る必要があります。デザインはそれらを、人が理解し、操作し、信頼できる流れにします。このつながりを作る人には、機能一覧では測りにくい価値を生む機会があります。
AI で実装の一部が容易になったとき、私が得たいのは、より大きな余裕です。取り組む価値のある問題を早く検証し、見せにくくても毎日起きる例外に、粘り強く向き合うための余裕です。
コードは舞台裏へ退いてかまいません。あの店主が再び急な日程変更に直面したとき、一度の処理で済み、確かに完了したと確認できる。そのとき初めて、プロダクトには選ばれ続ける理由が生まれます。