オブジェクト指向UIとは？｜画面を物から組み立てる

「画面の一覧を作ったら40枚を超えていました。機能を足すたびに1枚ずつ増えていきます」「制作会社に出した要件が『登録する』『修正する』『承認する』の並びになっていて、返ってきた画面もその並びのままでした」。——社内の業務システムや自社サービスの画面を発注する立場の人から、同じ形の相談が続けて届きます。この2つは画面の枚数や制作会社の力量の話に見えて、詰まっている場所はもっと手前にあります。画面を何の単位で数えるかが決まっていないので、機能が増えるたびに、数え方の外側へ画面が積み上がっていくのです。やることで数えるのか、扱う物で数えるのか。この記事では、その2つの割り方を並べて比べ、どちらを選ぶかを発注する側が判断できる形に組み立てていきます。

「やること」で数える画面と、「扱う物」で数える画面

画面の割り方には2つの流儀があります。1つは、やること（動詞）を起点に画面を立てる割り方です。もう1つが、扱う物（名詞）を起点に画面を立てる割り方で、こちらをオブジェクト指向UIと呼びます。2020年6月に出た解説書は、これをオブジェクト（もの、名詞）を起点としてUIを設計することと定義し、タスク（やること、動詞）を起点としたUIと対比しています。著者はデザイン会社と、その所属のデザイナー2名です。

具体で見ると差がはっきりします。請求書を扱う業務を、やること起点で割ると「請求書発行」「請求書修正」「請求書取消」「請求書照会」の4枚になります。物起点で割ると、請求書という物が1つあり、それを並べた一覧と、1件を開いた詳細の2つの形があり、発行・修正・取消はその詳細の中でできることになります。4枚が2枚に減ったのではなく、数える単位そのものが画面から物に変わったということです。

操作の順序も逆になります。オブジェクト指向のUIを解説した百科事典の項目には、この分野の設計者だったジェフ・ラスキンの指摘として、最も重要な特徴は動詞から名詞へではなく名詞から動詞への様式を採ることだ、という記述があります。先に対象を選び、それからできることを選ぶということです。やること起点の画面は逆で、先に操作を選ばせ、そのあとで対象を探させます。日常の道具はほとんど前者の順序で、書類を手に取ってから何をするかを決めます。

手順で割ると画面が増え、物で割ると増えにくい

増え方には構造があります。やること起点で割ると、扱う物の種類とできることの種類をかけ合わせた数だけ、画面の候補が生まれます。物が5種類、できることが6種類なら、理屈のうえでは30枚です。物起点で割ると、5つの物それぞれに一覧と詳細があるので10枚で、できることは詳細の中のボタンとして収まります。画面が増える速さが、かけ算から足し算に変わるのが、この割り方の効き目です。

機能を1つ足したときの差も具体的です。請求書に「差し戻し」を足すとします。やること起点で割っていると、新しい画面が1枚増え、メニューに項目が1つ増え、権限表に行が1つ増え、試験の対象も1画面分増えます。物起点で割っていると、請求書の詳細画面にできることが1つ増えるだけで、画面もメニューも権限表の行も増えません。1つの機能追加が4か所に波及するか1か所で済むかが、割り方だけで決まります。

次の表は、同じ業務を2つの割り方で組んだときに、どこがどう違ってくるかを並べたものです。見比べるべきは1行目ではなく、2行目から下です。画面の枚数そのものより、そのあとに続く運用の重さが変わります。

比べる点	作業の手順で割る	扱う物で割る
画面の数え方	やることの数だけ画面ができる。物の種類とかけ合わさって増える	物の数だけ一覧と詳細ができる。できることは画面の中に収まる
機能を足したとき	画面が1枚増え、メニュー・権限表・試験の対象も同時に増える	詳細画面にできることが1つ増える。画面の数は変わらない
画面の名前	「請求書発行」のように動詞で終わる。中身が想像しにくい	「請求書」のように物の名前で終わる。呼び名が業務と一致する
探し物の扱い	「検索画面」が別に立ち、条件と結果が離れる	一覧の絞り込みとして、一覧の中に収まる
権限の持たせ方	画面ごとに可否を持つ。入口が増えると閉め忘れが出る	物ごとに、できることの可否を持つ。入口が増えても行は増えない
利用者の進み方	決められた順にしか進めない。寄り道すると最初からになる	物を選んでから、その場でできることを選ぶ。順序は利用者が決める

いま何で割れているかを、画面の名前で数える

作り直しを検討する前に、現状を数えます。手順は簡単で、既存の画面一覧を出し、名前の末尾を見るだけです。「登録」「承認」「処理」「実行」「更新」で終わる名前は、やること起点で立った画面です。「照会」も同じです。物の名前で終わっている画面と、動詞で終わっている画面を、それぞれ数えます。この数え方なら、設計の知識がなくても1時間で終わります。

数えたあとの読み方を決めておきます。動詞で終わる名前が全体の半分を超えていれば、割り方そのものが手順側に寄っています。もう1つ見るのは、同じ物の名前が何枚の画面にまたがっているかです。1つの物について動詞名の画面が3枚以上あれば、その物は物起点に割り直す第一候補になります。全部を作り直すかどうかではなく、どの物から手を付けるかを決めるための数え方です。

メニューの階層も同じ目で見ます。第1階層が「登録業務」「照会業務」「日次処理」「月次処理」のように業務の時間割で並んでいる場合、利用者は触りたい物からではなく、いまが何の時間かから探すことになります。物の名前が第2階層より下にしか出てこない構造は、手順起点であることの分かりやすい印です。この構造は、新人が入るたびに手順書での説明が必要になります。

順番の1つ目：扱う物を洗い出して、粒度をそろえる

ここから3段の手順に入ります。1つ目は物の洗い出しです。解説書ではこの段をオブジェクトの抽出と呼びます。業務の手順書、既存の帳票、担当者どうしの会話に出てくる名詞を書き出し、関係を見て、粒度をそろえ、主役になる物を決め、その物が1件ずつ扱われるのか複数まとめて扱われるのかを区別し、主役に付いてくる物をその性質として持たせる、という流れです。拾うのは画面の名前ではなく、現場の人が口にしている名詞です。

いちばん手間がかかるのが粒度をそろえる作業です。「請求書」「請求書の明細」「今月の請求書」は、同じ並びには置けません。1つ目は物、2つ目はその物の一部、3つ目は物の一覧を絞った状態です。この3つを同じ一覧に混ぜたまま設計に入ると、画面の中に物と条件が同居して、名前が付けられなくなります。名前が付かない画面が出てきたら、粒度がそろっていない合図だと考えて戻ります。

内部の作りに引きずられない点も押さえます。先の百科事典の項目には、大手計算機メーカーが1987年に公表し、1992年に「オブジェクト指向のインターフェース設計」という題で指針集にまとめた画面設計の指針から、利用者が扱う物は作り手が使う部品やコードの単位と必ずしも対応しない、という記述が引かれています。同じ指針は、オブジェクト指向の作り方は役に立つが前提ではない、とも述べています。データを保持している表をそのまま画面の物にすると、利用者が呼んでいない名前が主役に座ります。

順番の2つ目：その物に対してできることを並べる

2つ目は、洗い出した動詞を物にぶら下げる作業です。業務の中の動詞を全部書き出し、それぞれがどの物に対する操作かで仕分けます。請求書なら、作る・直す・送る・取り消す・複製する・書き出す。得意先なら、登録する・住所を直す・取引を止める。仕分けが終わった時点で、画面ではなく機能の一覧ができあがっています。

ここで注目するのは、どの物にも所属しない動詞です。「月次を締める」がどの物にもぶら下がらないなら、締めという物が業務の中に存在していて、まだ拾えていない可能性があります。動詞が余ったときに画面を足すのではなく、物を足すかどうかを先に考えます。ここで画面を足してしまうと、せっかく物で割った構造に、手順起点の画面が1枚だけ紛れ込みます。1枚紛れると、その後も例外が増えます。

逆に、1つの物にできることが集まりすぎる場合もあります。20を超える操作が1つの物にぶら下がったら、その物が2つ以上の物を兼ねていないかを疑います。分けない場合は、出し方で差をつけます。よく使う操作は一覧の行から直接できるようにし、まれにしか使わない操作は詳細を開いた先に置きます。使いやすさの原則をまとめた1994年公表の10項目の第7項も、熟練した人向けの近道と初めての人向けの分かりやすさを両立させる、という書き方をしています。

順番の3つ目：一覧と詳細、2つの形を決める

3つ目は、物ごとに2つの形を決める作業です。複数を並べた一覧と、1件を開いた詳細です。解説書ではこの段を、ビューとナビゲーションの検討、レイアウトパターンの適用と呼んで分けています。物が決まっていれば、この段は絵を描く作業になり、それまでの2段のような業務の議論はほとんど起きません。逆に言えば、ここで議論が紛糾したら、物か動詞の仕分けが終わっていません。

出す項目の決め方には基準があります。一覧は選ぶための画面なので、選ぶために必要な項目だけを出します。詳細はその物のすべてを見る画面なので、項目を削りません。一覧に全項目を出すと横に長くなり、詳細に要約しか出さないと結局もう1画面必要になります。次の表は、2つの形の役割の違いをそろえて書いたものです。

決める項目	一覧（複数を並べる形）	詳細（1件を開く形）
この画面の役割	目的の1件を選ぶ。全体の量と状態を眺める	その1件のすべてを見て、その場で手を入れる
出す項目	選ぶために要る数項目だけ。状態と日付と識別する名前	その物が持つ項目を全部。関連する別の物への入口も置く
ここでできること	絞り込み、並べ替え、よく使う操作、複数まとめての操作	その物にぶら下がるできることの全部
名前の付け方	物の名前そのまま。「請求書」「得意先」	その1件を識別できる呼び名。番号や取引先名
やりがちな失敗	項目を足しすぎて横に長くなり、選ぶ役に立たなくなる	要約だけを出して、結局もう1枚の画面を呼ぶことになる

つなぎ方はここでは深追いしません。一覧から詳細へ、詳細から一覧へ戻れること、詳細から関連する別の物の詳細へ行けること。この3本が通っていれば、画面のつなぎ方の図は、物どうしの関係図からほぼ機械的に引けます。先の百科事典の項目も、この分野の特徴の1つとして、画面の中の物どうしが1つのまとまりとして噛み合うことを挙げています。

検索・絞り込み・並べ替えは、別画面ではなく一覧の性質

よく残るのが「検索画面」です。条件を入れる画面が1枚あり、実行すると結果の画面に移る形です。これは、探すという動詞から画面を立てた結果です。物起点で見ると、検索は請求書を探すという別の作業ではなく、請求書の一覧を絞る操作にすぎません。結果も新しい画面ではなく、同じ一覧が絞られた状態として返ります。

別画面にすると何が起きるかも書いておきます。条件を入れる画面と結果の画面が離れると、条件を変えるたびに戻る操作が要ります。先の10項目の第6項は、要素・操作・選択肢を見えるようにして記憶の負担を減らし、画面のある部分で見た情報を別の部分で思い出させないように、と書いています。いま何で絞っているのかが結果の隣に見えていないと、利用者は条件を覚えておくことになります。

収め方は3つです。並べ替えは一覧の見出し行に。絞り込みは一覧の上か横に、いま効いている条件が見える形で。文字での検索は一覧の中に。よく使う条件は保存して、一覧の入口に戻します。この3つを一覧の中に収めるだけで、画面の枚数は物の数だけ減ります。物が5つあれば、検索画面が5枚消える計算になります。

名前は、画面の名前ではなく扱う物の名前で付ける

割り方を変えると、名前の付け方も変わります。まずやめるのは「管理」「処理」「業務」で終わる名前です。「請求書管理」と書かれていても、一覧なのか、詳細なのか、設定なのかが読めません。物の名前で呼べば、一覧は「請求書」、詳細はその1件を識別できる呼び名になります。画面に名前を付けるのではなく、物の名前をそのまま画面の見出しにするということです。

利用者の言葉を使う点も外せません。1994年に公表され2024年に見直された10項目の第2項は、設計は利用者の言葉で話すべきで、内部の隠語ではなく利用者になじみのある語・言い回し・概念を使う、と書いています。社内の略称、システムの内部の呼び名、開発時の仮の名前を画面名に残さないということです。現場が「注文書」と呼んでいるものを画面で「受注伝票」と呼ぶと、問い合わせのたびに翻訳が要ります。

名前を直すと、周辺がまとめて揃います。次のように直すと、権限表・手順書・問い合わせの言い方が同じ語になります。同じ10項目の第4項も、同じ語・同じ状況・同じ操作が同じ意味かどうかを利用者に考えさせない、と書いています。

• 「請求書管理」を「請求書」に——一覧であることが画面の形で分かるので、名前で説明しなくてよい
• 「請求書発行処理」を「請求書の詳細にある『発行する』」に——画面ではなく、物にできることとして持つ
• 「得意先マスタ保守」を「得意先」に——保守という内部の言葉が、利用者の画面から消える
• 「日次締め処理画面」を「締めの一覧と、その詳細」に——締めが物になり、過去の締めも同じ形で見られる
• 「受注伝票検索」を「注文の一覧の絞り込み」に——現場の呼び名に合わせ、検索を一覧の中に収める

権限は物ごとに持たせる。作業ごとだと穴が開く

権限の持たせ方も、割り方に引きずられます。やること起点で作ると、権限は画面ごとの可否になります。この形は、画面が増えるたびに権限表の行が増え、しかも同じ物に別の入口ができたときに、片方だけ閉め忘れます。差し戻し画面には権限をかけたが、一覧からの一括操作には同じ権限がかかっていない、という穴がこの形の典型です。

物起点で持つと、表の形が変わります。行が物、列ができること（見る・作る・直す・消す・承認する）になり、交点に可否が入ります。新しい入口が増えても、その入口が既存の行と列を参照するだけなので、権限表は増えません。権限表の行数が画面の数と一致していたら、権限が画面に付いている印です。行数が物の数と一致していれば、物に付いています。

条件付きの権限も同じ場所に置きます。「自分が作った請求書だけ直せる」「支店をまたぐ請求書は見られない」といった条件は、物の側の決めごととして書きます。画面側に書くと、別の入口から同じ物に触れたときに条件が効きません。可否を確かめる場所は、画面ではなく物の側に1か所だけ置きます。この1か所主義は、あとから監査で確認を求められたときにも効きます。

物で割ると、利用者が自分の順で進める

使い勝手の差がどこから来るのかも押さえておきます。2020年10月に公開された論考は、タスク指向を、ゴールをあらかじめ想定してそこに向けて最適化しているもの、オブジェクト指向を、利用者が自分なりの方法で目的に向かっていけることを前提にするもの、と対比しています。同じ論考は、手順で作りたくなる癖の出どころを、機械に長い処理を埋め込むという計算機側の都合に求めています。

業務は順番どおりには進みません。途中で電話が入る、差し戻しが来る、先に別の物を確かめたくなる。手順で割った画面は、この寄り道のたびに最初からやり直しになります。最初からやり直しになる作りは、慣れた人ほど画面を使わずに手元の表計算で処理を始める原因になります。10項目の第3項も、人は誤って操作するものだから、長い手順を踏まずに離脱できるはっきりした非常口が要る、と書いています。

副作用も正直に書いておきます。自由に行き来できるということは、抜けや順序違いも起きやすいということです。物起点で割る場合は、必須の項目が埋まっていない状態を物の側の状態として持ち、一覧でその状態が見えるようにします。順序で縛る代わりに、状態を見せて気づかせるのが、こちら側のやり方です。この置き換えを忘れると、自由なだけで抜けの多い画面になります。

この考え方が向かない場面

向かない場面もはっきりしています。順序に理由がある一本道の手続きです。申込、本人確認、決済、契約の同意。順番が業務上または法令上の要請で決まっていて、途中で行き来されると手続きとして成立しません。ここはやること起点で割るほうが素直です。2025年9月に公開されたデザイン会社と事業会社の対談でも、業務プロダクトではもともとの業務自体が手続き的でタスク指向である場合がある、と課題として挙げられています。

混ぜ方を決めておけば、両立します。全体は物で割り、一本道の手続きだけを、その物の詳細から呼び出す形にします。手続きが終わったら、必ずその物の詳細に戻します。手続きを入口にすると、手続きの数だけ入口が増えて、結局やること起点の構造に戻ります。入口は物、手続きは物から呼ぶもの、という関係を崩さないことが条件です。

物起点にしようとして失敗する型も、あらかじめ知っておくと避けられます。次に挙げたのは、順番を飛ばしたときに出てくる典型です。共通しているのは、物が決まる前に画面の話を始めていることです。

• 物が決まる前に画面の絵を描き始める——名前が付かないまま枚数だけ増え、途中で全部描き直しになる
• データを保持している表をそのまま物にする——利用者が呼んでいない名前が主役に座り、現場との会話が噛み合わない
• 年に数回の例外業務まで一覧と詳細に押し込む——日常の画面が複雑になり、毎日使う人の作業が遅くなる
• 一覧を作ったが、そこから何もできない——見るだけの一覧は、結局その先に操作用の画面をもう1枚呼ぶことになる
• 粒度をそろえずに全部の名詞を物にする——一覧が30本並び、どれが主役なのか利用者にも作り手にも分からなくなる
• 動詞名の画面を1枚だけ残す——例外を1つ認めると、以後の追加も例外として積み上がる

生成AIに画面案を出させると、手順の並びになりやすい

画面案づくりに生成AIを使う場面が増えました。ここには割り方に関わる落とし穴があります。指示の書き方が動詞から始まるからです。「請求書を登録できる画面を作って」と書けば、返ってくるのは登録画面です。要件定義の文書をそのまま渡しても、要件が「〜できること」の並びで書かれている以上、返る画面もその並びのままになります。指示の文法がそのまま画面の割り方になる、というのがこの道具の性質です。

だから渡し方を変えます。先に物の一覧を渡し、枠を固定してから中身を書かせます。具体的には、扱う物はこの5つであること、それぞれに一覧と詳細を作ること、できることは各物にぶら下げること、動詞から画面名を作らないこと、の4点を条件として先に書きます。物の一覧を渡さずに画面案を求めると、AIは指示文の動詞から画面を組み立てます。渡す順番を変えるだけで、返ってくる案の構造が変わります。

できることの限界も知っておきます。2025年9月に公開された対談で、デザイン会社のコンサルタントは、現時点で画面の生成において実用に耐えうる品質と思えるものはなさそうだと述べたうえで、買い物かごのように既存の概念があるものは生成できる可能性が高い一方、新たに創発するような発明となる領域はまだ十分に言語化されておらず、当面は人間が担う必要がある、と指摘しています。見慣れた形をなぞらせる用途と、業務に固有の物を決める用途は、同じ道具でも当たり外れがまったく違うということです。

AIに決めさせない範囲を、先に紙に書く

任せる範囲を書いたら、任せない範囲も同じ紙に書きます。片方だけを配ると、書かれていないほうが自動的に許可されたことになります。この記事の話題でいちばん外せないのは2つです。どの物を主役に置くか。画面を増やしてよいかの判断。この2つは、業務の言葉と組織の事情を知っている人しか決められません。

• どの物を主役にするか——現場が日常で口にしている名前かどうかは、その業務を見ている人にしか判定できない
• 画面を増やしてよいか——1枚増えると、権限・試験・手順書・問い合わせ対応が同時に増える。増分は画面の外にある
• 物の粒度をまとめる分けるの判断——まとめすぎても分けすぎても使いにくくなる。境目は業務側の頻度と担当の分かれ方で決まる
• 名前の最終決定——社内の呼び名と、法令や取引先との書類上の名称が食い違っている場合がある
• 例外業務を日常の画面に載せるか——年に数回の作業のために毎日の画面を複雑にしてよいかは、頻度を知る人が決める

根拠を書かせる指示も一緒に入れます。物を提案させるなら、その名詞が業務のどの文書、どの会話に出てきたのかを、物ごとに1行で書かせます。書けない物は、渡した資料の外から言葉の並びで作られた物です。加えて、判断に必要な情報が足りないと思ったら、案を作らずに何が足りないかを書いて止まるよう、指示に1行足します。止まった回数は数えておきます。止まらない道具は、いつも何かを埋めているということだからです。

人が確かめる範囲も3つに決めます。提案された物の名前が現場で実際に使われている言葉か。物ごとに一覧と詳細の2つがそろっているか。できることが物にぶら下がっていて、動詞で終わる画面名が混じっていないか。3つに絞ると、案の数が増えても確認が作業として回ります。全部を読み直そうとすると、件数が増えた時点で確認が形だけになり、線を引いた意味がなくなります。

制作会社や情報システム部門と合意するとき、何を渡すか

外に出すときに渡す資料も、割り方に合わせて変えます。渡すのは3点です。物の一覧（名前と一言の説明）、物ごとにできることの一覧、一覧と詳細それぞれに出す項目の一覧。この3点があれば、画面の絵がなくても見積もりの単位が決まります。絵から入ると、絵の枚数の話になって、割り方の合意が後回しになります。

見積もりの言い方も変わります。「画面40枚」ではなく「物が5つ、一覧と詳細で10画面、できることが18種」と書きます。あとからできることが1つ増えたときに、画面1枚分ではなく、できること1つ分の追加として話せます。変更依頼の書き方も同じで、「この画面に項目を足してほしい」ではなく「この物にこの性質を足してほしい」と書くと、一覧・詳細・書き出しのどこに反映すべきかが自動的に決まります。

合意の前に確かめる項目を並べておきます。次の6点は、提出された設計が本当に物起点になっているかを、絵を読まずに判定できるものだけを選んでいます。1つでも外れていたら、絵の直しではなく割り方の議論に戻します。

• 物の名前が、現場で実際に使われている言葉と一致しているか。社内の略称や内部の呼び名が混じっていないか
• 物ごとに、一覧と詳細の両方が用意されているか。片方しかない物があれば、その理由が書かれているか
• 動詞で終わる画面名が残っていないか。残すなら、一本道の手続きであるという理由が添えられているか
• 検索・絞り込み・並べ替えが、別画面ではなく一覧の中に収まっているか
• 権限表の行が、画面ではなく物になっているか。行数が物の数と一致しているか
• 一本道の手続きが、どの物の詳細から呼び出され、終わったあとどこへ戻るかが決まっているか

既存の画面がすでに手順で割られているときの進め方

いま動いている画面が手順起点でも、全部を一度に変える必要はありません。2025年9月の対談でも、既存のものがタスク指向の場合、それをオブジェクト指向に変えるのはどうしても難しくなる、という指摘が出ています。難しいのは技術ではなく、業務の側がすでにその手順で回っていることのほうです。だから、物を1つずつ移します。

移し方は5段に分けられます。順番を守ると、途中で止めても壊れません。

移行の途中は、2つの割り方が同居します。同居が長引くほど、利用者は同じ物に2つの入口を見ることになり、どちらが正しいのかを毎回迷います。だから、物1つあたりの移行は期間を区切って終わらせ、終わるまで次の物に手を付けません。同時に3つの物を移し始めると、どの画面が新しい側なのかを説明する手間が、移行の効き目を食い潰します。

まとめ

画面設計の分かれ目は、枚数ではなく何を1枚と数えるかにあります。やることで数えると、扱う物の種類とできることの種類をかけ合わせた数だけ画面の候補が生まれ、機能を1つ足すたびに画面・メニュー・権限表・試験の対象が同時に増えます。扱う物で数えると、物の数は変わらないので、増えるのはその物にできることのほうです。増え方が、かけ算から足し算に変わります。

順番は3段でした。物を決める。その物に対してできることを決める。一覧と詳細の形を決める。1段目でいちばん手間がかかるのは粒度をそろえる作業で、物と、物の一部と、物を絞った状態を混ぜないことが要点です。内部でデータを保持している表をそのまま物にしない、というのも外せません。利用者が扱う物は作り手のコードの単位と必ずしも対応しない、というのは1980年代の画面設計の指針にすでに書かれていた話です。

この3段を通すと、後ろがまとめて揃います。名前は画面の名前ではなく物の名前になり、現場の呼び名と一致します。検索・絞り込み・並べ替えは別画面ではなく一覧の性質として収まり、物の数だけ画面が減ります。権限は画面ごとではなく物ごとになり、入口が増えても表の行は増えません。名前と検索と権限は、割り方を直せば後から自動的についてくるものであって、個別に直すものではありません。

ただし万能ではありません。申込や本人確認のように順序に理由がある一本道の手続きは、やること起点で割るほうが素直です。全体は物で割り、その部分だけを物の詳細から呼び出し、終わったら詳細に戻す。この関係を崩さないことが、混ぜるときの条件でした。向かない場面を隠さずに書いておくほうが、社内での合意は早く取れます。

生成AIとの付き合い方も、この記事の結論の一部です。指示を動詞で書けば動詞の画面が返るので、物の一覧を先に渡して枠を固定します。決めさせないのは、どの物を主役に置くかと、画面を増やしてよいかの2つ。提案された物には、その名詞が業務のどこに出てきたかを1行で書かせ、人が確かめるのは3点に絞る。生成AIが返すのは画面の候補であって、何を主役に置くかという決定ではありません。候補として扱えば作業は速くなり、決定として扱えば、現場が使っていない名前の画面が増えていきます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。