相談を、考えに。考えを、使える仕事に。Gt.Onで伝えたいAIとの向き合い方

答えをもらって終わらない。自分の問いから、次に進める仕事をつくる。

株式会社S.Line 代表取締役／Gt.On運営者

岡田 颯太（おかだ そうた）

はじめまして。株式会社S.Line代表取締役の岡田颯太です。SNS運用、教育、企業支援に携わり、ChatGPT・Codexを中心とする専門メディア「Gt.On」を運営しています。

AIへ相談する最初の言葉は、整理されていなくてもよいと僕は思っています。

「何かを良くしたいけれど、問題をうまく説明できない」「案はあるけれど、何から始めればよいか分からない」「資料は集めたけれど、決めるための形になっていない」。仕事の始まりには、そうした曖昧さがあります。

大切なのは、その曖昧さを、最後まで曖昧なままにしないことです。

何を決めたいのかを言葉にする。足りない材料を確かめる。比較できる案をつくる。選んだ理由を残す。そして、実際に使う成果物へ進める。

Gt.Onでは、ChatGPTやCodexを、その流れのどこで使い、どこを人が判断するかを深く扱いたいと思っています。

単発で良い答えを引き出すことだけではなく、考えたことが次の仕事に残ること。AIとの対話が、現実の行動へつながること。それが、このメディアで僕が実現したい価値です。

01｜岡田颯太のプロフィール

項目	内容
氏名	岡田 颯太（おかだ そうた）
英語表記	Sota Okada
発信名	ソウタ
所属・役職	株式会社S.Line 代表取締役
出身	群馬県太田市
学歴	群馬大学 教育学部 数学専攻 卒業
保有資格	小学校教諭一種免許状、中学校教諭一種免許状〈数学〉、高等学校教諭一種免許状〈数学〉
主な領域	SNSマーケティング、SNS教育、企業向け運用支援、AIの実務活用

経歴と資格は会社公式プロフィール、役職と事業領域は会社概要で公開しています。

これらは公表済みの実績であり、現在値のリアルタイム集計ではありません。SNS実績の出典

ただ、Gt.Onで示したい専門性は、数字の大きさだけではありません。自分の考えを言語化すること、相手に伝わる形へ変えること、実際の制作や運用へ落とし込むこと。その間を、現場と教育の視点でつなぐことです。

公開している発信・メディア活動

会社公式では、週刊エコノミストへの掲載、TOKYO MX「HISTORY」への出演、テレビ「シゴト手帳」への出演、サンクチュアリ出版との共同セミナーなどを活動として紹介しています。メディア・登壇活動の出典

相手が何を知りたいかを考え、分かる言葉にして返すことは、対話にも記事にも共通します。Gt.Onでは、過去の掲載や肩書きだけで納得してもらうのではなく、読者の問いが実際の仕事へ進む説明を積み重ねていきます。

僕がAIとの対話で増やしたいのは、答えの数より選べる理由

ChatGPTやCodexを扱うGt.Onで、僕は、上手な返答を一回引き出すことだけをゴールにしたくありません。相談する前には曖昧だった仕事が、何を決め、何を作り、どう確かめるかまで見えるようになることを目指したいと思っています。

これは、AIにすべての判断を任せるという意味ではありません。むしろ、自分が何を判断しなければならないかを明らかにするために、対話を使うという考え方です。

経営でも教育でも、最初から課題が正確な文章になっているとは限りません。何かがうまくいっていない気がする。作りたいものはあるが、どこから始めればよいか分からない。複数の案があるのに、決めるための条件がそろっていない。そうした状態から仕事は始まります。

僕は、その曖昧さを、相談する人の能力が足りない証拠として扱いたくありません。何が分かれば次へ進めるかを、一緒に見つける余地があるからです。すぐに大きな解決策を出すより、まず一件の仕事に戻り、目的、材料、条件を整理します。

良い答えを持つ人になるだけでなく、自分に必要な問いをつくれる人になる。その力を、AIとの対話と実際の行動の両方から育てたい。この視点が、Gt.Onで僕が発信する理由です。

02｜「分からない」を、具体的な問いに変える原体験

公式プロフィールでも紹介しているとおり、中学生時代には偏差値39から学び方を見直した経験があります。その後、群馬大学教育学部で数学を専攻しました。学生時代の経歴

今、僕がその経験から大切にしたいのは、分からないことの中身を分ける姿勢です。

答えの意味が分からないのか。解く手順が分からないのか。どの考え方を使うか選べないのか。それを分けると、次に聞くことも、練習することも変わります。

AIとの対話でも、同じように考えたいと思っています。

「うまく使えない」という悩みを、すぐに使う人の能力の問題にしない。目的を説明できていないのか、必要な材料がないのか、出力の良し悪しを判断する基準がないのかを考えます。

最初から完璧なプロンプトを書けなくても構いません。対話を通じて、問題の形をはっきりさせていけばよいのです。

僕がGt.Onで教えたいのは、正解の言葉を暗記することではなく、自分の状況に合う問いをつくることです。

「分からない」を分ける経験が、今の対話の基準になっている

僕は中学生時代、勉強がうまくいかない状態から、成績のよい人の取り組み方を観察し、自分の学び方を変えた経験があります。その後は群馬大学教育学部で数学を学び、塾講師として子どもたちにも関わりました。経歴の出典

この経験から現在に持ち帰りたいのは、分からないという言葉を、一つの状態として扱わないことです。問いの意味が分からないのか、必要な知識が足りないのか、どの考え方を使うか選べないのか、途中の計算や操作で止まるのか。それぞれ必要な支援は違います。

AIの相談でも同じです。返答が気に入らなかったとき、すぐに「このAIは駄目だ」と決めるのではなく、目的を共有できていたか、材料が不足していなかったか、何を完成物とするかを示していたかを見たいと思っています。

一方で、依頼する人がすべての不足を見抜ける前提にもしたくありません。最初のやり取りを通じて、自分が確認していない条件に気づくことがあります。その気づきを質問へ変えれば、対話した意味があります。

僕が教えたいのは、特定の正しいプロンプトを暗記する方法だけではありません。仕事の状態を説明し、返ってきた内容を確かめ、不足しているものを見つけて、次に聞くことを選ぶ方法です。問いをつくること自体が、仕事を理解する練習になる。その入口を届けたいと思っています。

03｜教育の原点には、本人が自分から進む瞬間がある

両親が教員で、自分も教育学部で学び、大学時代には塾講師として子どもたちと関わりました。その後、SNSを教える仕事では、幼なじみからの相談が一つのきっかけになりました。

最初は料金を取らず、自分が実践していたことを伝えました。その経験を通じて、自分の知識が、誰かの「やってみたい」を進めるために使えることを実感しました。

今の教育で僕が大切にしたいのも、答えを届けることだけではありません。本人が何をしたいかを考え、分からないところを言葉にし、自分の判断で次へ進むことです。

AIとの対話でも、その姿勢を持っていたいと思います。最初から整った依頼を言えなくても、問いを通して状況が見えるようになる。完成例を見た後に、自分の材料へ戻って考えられるようになる。

だからGt.Onでは、プロンプトの正解集を渡すことだけを目的にしません。読者が自分の問いをつくり、その答えを仕事へ使うところまでを考えます。

対話を、答えをもらう場所から、自分の考えを育てる場所へ。教育を原点にしている僕だからこそ、その使い方を深めたいと思っています。

人に教えるようになって、答えを急がない意味が変わった

僕がSNSを教える仕事へ進んだきっかけには、自分の発信を見た幼なじみからの相談があります。最初は無料で実践したことを伝え、その経験から指導の仕事を広げていきました。

自分が経験した方法を説明できることと、相手が自分で使えるようになることは同じではありません。自分にあった材料が、相手にもあるとは限らない。自分が迷わず決められたことでも、相手には選ぶ理由が見えていないかもしれない。その違いを理解する必要があります。

だから、問いを返すことにも意味があります。ただ答えを遠回しにするためではなく、本人が何を理解し、どこを確認していないかを確かめるためです。本人が考える前に完成文を渡しすぎると、きれいな作品はできても、その人にどんな判断が残ったかが見えにくくなります。

AIで学ぶときにも、今は答えの候補が必要なのか、自分の初案を見直す質問が必要なのかを分けたい。用途が違えば、よい返答の形も変わります。

僕がGt.Onで届けたい対話は、いつも結論を早くする対話ではありません。考える必要がある部分は残し、迷っている対象を具体化し、その人が自分の言葉で次へ進めるようにする対話です。速さを使いながら、学ぶ人の主体性まで置き去りにしない。その付き合い方を大切にしていきます。

04｜情報を知る側から、自分で仕事をつくる側へ

大学卒業後に入社した自動車部品会社を約2ヶ月で退職し、SEO、WordPress、ブログ、SNS運用などに取り組みました。フリーランスとして活動した後、2023年3月に株式会社S.Lineを設立しています。会社公式の経歴

この経歴を、特定の働き方を選ぶべきだという話にはしたくありません。僕が今の教育へつなげて考えたいのは、情報を知ることと、自分の仕事をつくることの間にある過程です。

調べた方法を、自分の条件へ合わせる。実際に文章や投稿を作る。結果を見て、どこを変えるか考える。必要なことを、また学ぶ。

誰かの説明を受け取るだけでなく、自分の判断を一つずつ持つ必要があります。

SNSを運用する側から、他者を支援する側へ進むと、さらに問いが増えます。相手の目的は何か。何を約束したか。どこまでが自分の担当か。誰の確認が必要か。

僕は、その仕事の問いをAIとの対話へ持ち込みたいと思っています。一般的な正解をたくさんもらうより、今の一件を前へ進めるために使う方向です。

05｜ChatGPTへ相談するとき、すぐに答えを求めないこともある

相談したいことが曖昧なとき、僕なら「最適な方法を教えて」で始める前に、何を整理すべきかを考えます。

目指している状態は何か。今どこで止まっているか。何をすでに試したか。どんな条件を変えられないか。何がまだ確認できていないか。

最初から全部が言葉になっていなくても、対話によって分けていくことはできます。

たとえば「投稿を改善したい」という相談でも、企画が決まらないのか、原稿が書けないのか、公開後の反応を説明できないのかで、必要な答えは違います。

そこを確認せず、すぐに企画案を大量に出してもらうと、今の課題とずれたまま仕事だけが増えるかもしれません。

僕は、AIに早く結論を出させることだけを、上手な使い方とは考えていません。必要な問いが見つかり、その問いに答える材料がそろうことにも価値があります。

まだ決められないことを、決めたようにしない。まず、何を決める話なのかをそろえる。

それが、Gt.Onで伝えたい対話の出発点です。

06｜曖昧な相談を、決めることが見える会話へ変える

「集客を良くしたい」「AIをもっと使いたい」「仕事を整理したい」。こうした相談は、出発点として自然だと思います。

ただ、すぐに施策を大量に並べると、どこから始めるか分からないまま情報だけが増えることがあります。

僕なら、今の状況、望む変化、使える材料、決める必要があることを分けます。答えを急ぐより、何について相談しているかをはっきりさせる段階を置きます。

例えば「SNSを良くしたい」なら、自分の発信なのか、顧客の運用なのか。新しく始めるのか、既にある投稿を直したいのか。誰に何を届けたいかは決まっているのか。

これが分かれば、次に読む資料や作るものが変わります。プロフィールの一文を直す仕事かもしれませんし、商品説明の素材を集める仕事かもしれません。

僕がAIとの会話で重視したいのは、回答の情報量より、相談の焦点が合っていくことです。本人が望んでいない事業や働き方へ、会話が勝手に進まないようにします。

言葉にできていないことを責めず、言葉になったつもりにもならない。その間を丁寧に進めたいと考えています。

07｜依頼の上手さは、長さではなく前提の一致で考える

詳しい指示を書けばよい、というだけではありません。長い文章でも、重要な条件が抜けていれば、必要な仕事は定まりません。

僕なら、依頼を五つに分けます。目的、材料、制約、完成物、確認方法です。

目的は、誰が何を決めたり行ったりするための仕事か。材料は、使ってよい事実や資料。制約は、変えてはいけないことや使える条件。完成物は、文章なのか、表なのか、実際に動く仕組みなのか。確認方法は、それが使えると判断する基準です。

これを全部、難しい言葉にする必要はありません。「この資料だけを根拠にする」「日付が分からなければ未定と書く」「まず案を比較し、本文はまだ作らない」といった具体的な説明でよいのです。

不足があれば、AIの返答をきっかけに追加で整理します。ただし、質問を受けたことと、その前提が実際に確認できたことは分けます。

僕が残したいのは、特定の言い回しを唱えると良い答えが出るという理解ではありません。自分の仕事の条件を共有できれば、修正も判断も具体化しやすくなるという理解です。

08｜一枚の依頼書で、何を任せるかをそろえる

僕が依頼を整理するなら、長い背景を全部書くことより、次の仕事に必要な条件をまとめます。

ここでは、架空のオンライン説明会の案内を作る例を考えます。実在の講座条件や販売施策ではありません。

目的は、参加を検討している人が、自分に関係する内容か判断できる案内文を作ること。材料は、確認済みの開催概要と、過去に受けた質問の匿名化した要点。未確定の日時や特典は、そのまま未確定として扱います。

依頼に置く項目	この例で渡す内容
今回の目的	参加を検討する人が、対象と内容を理解できること
使う材料	確認済みの概要、使用許可のある質問の要点
変えないこと	提供内容、対象、未確定事項の扱い
欲しい成果物	案内文の下書きと、不足している確認の一覧
まだ行わないこと	外部への送信、未承認の特典追加、成果の保証
確認すること	案内を読んで対象・内容・次の行動が分かるか

これだけでも、単に「集客できる文章を作って」と頼むより、仕事の範囲が見えます。

出力が足りなければ、この依頼書へ戻れます。材料不足なのか、構成が合っていないのか、指示が曖昧だったのかを話せるからです。

僕は、上手な依頼文を一度つくって終えるのではなく、実際の出力を見ながら、依頼する側の説明も改善したいと考えています。

09｜同じ会話の中に、事実と案を混ぜない

対話が進むと、資料から確認した内容、AIが出した候補、自分が考えた案、すでに採用した方針が並びます。

僕は、その区別を保ちたいと思っています。

まだ検討している価格を、正式な価格として案内文へ入れない。AIが提案した施策を、すでに実施した活動として振り返らない。会話で仮置きした数字を、実際の結果として扱わない。

そのために、確定したこと、仮に置いたこと、確認が必要なことを分けて残します。

また、「前に話したから知っているはず」と決めつけないようにしたい。継続する仕事では、今回の判断に必要な資料と決定事項を、確かめられる形にして渡します。

ChatGPTのプロジェクトは、関連するチャット、ファイル、指示をまとめる機能として公式に案内されています。ただし、それだけで必要な情報が常に漏れなく参照される保証にはしません。OpenAI公式：ChatGPTのプロジェクト

道具の文脈管理と、仕事の正式な記録を分けて考える。これが、長く続く仕事で僕が重視したいことです。

10｜会話の中で変わったことを、短い記録に残す

長く相談していると、最初の案と、途中で決めたことと、まだ検討していることが混ざりやすくなります。

僕なら、節目で「現在の目的」「採用した案」「変更した条件」「未確認」「次に作るもの」を短く整理します。

これは、AIがすべてを確実に覚えていると期待する代わりに、仕事の前提を見える形にするためです。別の人へ渡すときや、別の会話で続きを行うときにも役立ちます。

例えば、最初は長い資料を作る予定だったが、先に短い案内だけ必要になったなら、その変更を残します。新しく決まった提供条件があるなら、どの資料で確認したかを記録します。

そのうえで、古い案を現在の決定として再利用しないようにします。会話が長いこと自体を、理解が深まった証明にはしません。

話した量より、いま何を前提に進めるかが一致していること。ChatGPTを仕事へ使うときにも、人との会議でも、僕が大切にしたい基準です。

長い会話の価値は、次の一件へ戻れるかで考える

AIとの会話が長くなると、多くの案や修正が蓄積します。しかし、会話が多いことと、仕事の状態が分かることは別です。

最初の案と後から変更した案が並んでいる。検討しただけの内容と、採用した内容が同じように書かれている。できたはずのものが、どこにあるか分からない。この状態では、次に人が引き継いでも、また最初から判断をたどる必要があります。

僕なら、一つの区切りで現在の仕事を言葉にします。何を目的にしているか。何を採用したか。何は採用していないか。どの成果物が今の版か。残っている確認は何か。次に誰が何をするか。

これは、会話を短くすることだけが目的ではありません。大切な前提を残し、次の一件を始めるためです。担当者が変わったときにも、前の会話をすべて暗記しなくてよい状態をつくりたいと思っています。

僕がAIを仕事に使うとき、最終的に残したいのは、話した量の多さより、再開できる記録です。人がいなくても勝手に進むと約束するのではなく、人が戻ってきたときに何を確かめればよいかが分かる。それも、対話を実務へ変える品質の一つです。

11｜「良さそう」という反応と、実行してよい範囲を分けて考える

AIとの会話では、案について話しているうちに、それが決定事項のように扱われることがあります。僕は、その切り替わりを曖昧にしたくありません。

ここでは、仕事を進めるための独立した架空の会話を考えます。相談者は、顧客への案内文の方向性を見て「良さそう」と返しました。ただし、誰へ送るか、いつ送るか、正式条件との照合が終わったかは、まだ話していないという設定です。

この場面で、文案への好意的な反応を、そのまま送信の承認として扱うことはしません。「良さそう」が何を指しているかは文脈で確認します。表現の方向への賛同か、本文の採用か、外部への実行まで含む指示かは別だからです。

進められることと、まだ確認することを示す

僕なら、文案の整理や、未確定の項目をまとめるところまで進めます。そのうえで、次のように返します。

文案の方向性は、この案で整えます。現時点で進めるのは原稿の仕上げまでです。送信先、送信時期、正式な提供条件の確認がまだなので、送信済みとは扱いません。原稿と確認事項を分けてお渡しします。

これは実際に送信した記録ではなく、会話の状態を明確にするための架空の返答です。

曖昧さを理由に、すべてを止めない

確認が必要な部分があっても、勝手に実行しない範囲でできる仕事はあります。候補を比較する、文案の誤字を直す、確認欄を作る、根拠の資料を整理する。依頼の目的を理解して、進められる作業を進めます。

一方、外部へ通知する、既存の情報を変更する、費用の発生する処理を行うなど、影響がある行為は、それぞれの権限と指示の範囲を確認して扱います。これは作業を遅くするためではなく、考えたことと実行したことを混ぜないためです。

最終的に実行したなら、文案ができた記録とは別に、何をどこまで行い、結果をどう確認したかを示します。途中の段階でも、その状態を正しく伝えられる方が次の判断に役立ちます。

会話が前へ進むことと、勝手に決定事項が増えることを分ける。Gt.Onでは、対話を仕事につなぐときの、その精度を大切にしたいと思っています。

良さそうな案と、実際に行ってよいことを分ける

話しているうちに、よい案が見つかることがあります。そのとき、「それは良さそう」という反応と、外へ送ったり、公開したり、既存の記録を変更したりしてよいという判断を、同じものにしないようにしたいと思っています。

下書きができることと、そのまま顧客へ送ってよいことは別です。ページを試作することと、本番のページを書き換えてよいことも別です。整理案を提示することと、元の資料を削除してよいことも違います。

僕は、何を作ってよいかだけでなく、何はまだしないかを言葉にします。人が確認する対象、外へ出してよい版、実行する担当も分けます。その境界があることで、準備の仕事を安心して進められると考えています。

慎重に扱うことを、何も進めない理由にはしたくありません。公開の判断がまだでも、原稿を整え、必要な質問をまとめ、比較できる案を用意することはできます。実行できない部分と、今できる準備を分ければ、確認待ちの時間も次へつながります。

考える、つくる、確認する、実行する。それぞれを同じ「進める」にまとめない。その区別を、ChatGPTやCodexの話題でも、実際の業務の場面に合わせて伝えたいと思っています。

12｜AIを、賛成してもらうためだけには使わない

自分の案があると、良い点を見つけてほしくなることがあります。ただ、僕はAIを安心するためだけの相手にしたくありません。

その案が成り立たない条件は何か。ほかの選択肢はあるか。いま優先しなくてよい作業は何か。自分が見落としている負担はないか。

こうした問いも、一緒に扱いたいと思っています。

たとえば新しい企画を考えるなら、面白さだけでなく、使える素材、制作に必要な時間、読者への約束まで見ます。新しい仕組みを考えるなら、作ることだけでなく、保守や説明の仕事も考えます。

反対意見を出してもらったからといって、それが正しいとは限りません。それも検討する材料です。根拠がある指摘なのか、条件が違う一般論なのかを確認します。

僕は、AIに最終判断を預けるより、自分が比較するための視野を広げたいと思っています。

自分の考えを強く見せるためではなく、考えを見直せるように使う。

その対話が、企画や経営の仕事に役立つと考えています。

13｜選択肢を増やす会話と、選ぶ会話を分ける

アイデアを出す段階では、幅を広げることに意味があります。ただ、案が増えるほど、選ぶための条件も必要になります。

僕は、考えられる方法を出す時間と、今回どれを選ぶかを決める時間を分けたいと思っています。

例えば、SNSから相談につなぐ方法を考えるなら、投稿、固定投稿、プロフィール、説明ページなど、いろいろな案が出ます。その後は、今どこで相手が迷っているのか、どんな素材があり、どこを直せるかへ戻ります。

案の数だけでは、次の仕事は始まりません。比較する軸がそろって初めて、自分の条件で選べます。

AIに反対の見方を出してもらうときも同じです。多くのリスクを挙げてもらうだけでなく、どれが今回の条件に関係し、何を確認すればよいかを分けます。

僕がAIとの対話で増やしたいのは、選択肢の在庫だけではありません。案を広げ、絞り、試す理由を持てることです。

発想の自由と、実行の焦点を行き来する。その会話の使い分けを、Gt.Onで具体的に伝えていきます。

経営者としてAIへ相談するとき、自分の責任が残る場所を見る

経営では、何を選んでもすべてがよくなるとは限りません。時間を一つの仕事へ使えば、別の仕事に使える時間は減ります。新しい仕組みを導入すれば、準備や維持の仕事が生まれます。制作物を増やすなら、それを確認する人の時間も必要です。

僕は、AIへ相談するときにも、選択によって誰にどんな負担が生まれるかを考えたいと思っています。魅力的な案が出てきたからといって、実行する条件がそろったことにはなりません。

そこで、案の利点だけでなく、必要な材料、担当、継続する仕事、見直す条件を並べます。自分が期待している結果と、現時点で確認できている事実も分けます。うまくいく理由を探すのと同じように、採用しない方がよい条件も見ます。

AIに反対意見を出してもらうことも、最終判断を外へ預けることではありません。その指摘が今回の状況に当てはまるかを、さらに確かめるためです。根拠のない賛成も、条件に合わない反対も、そのまま結論にはしません。

相談を重ねることで、自分の責任を薄くするのではなく、自分が引き受ける判断をはっきりさせる。経営者として、AIをそのための相手にしたいと考えています。選んだ理由を人へ説明できる状態で、現実の仕事へ進むことを大切にします。

14｜具体例：曖昧な制作相談を、使える依頼へ変える

ここでは、考え方を示すために作った架空の制作チームを題材にします。実際の社内導入や顧客成果ではありません。

担当者の相談は「制作の依頼が散らばっていて、何から進めればよいか分からない」。チャットには修正依頼があり、表には納期があり、別の資料には作業範囲がある、という設定です。

僕なら、最初から専用アプリを作るとは決めません。

まず、何が分からないのかを確かめます。担当者なのか、最新版なのか、承認状態なのか、期限なのか。問題が一覧の不足なら、既存の表を直すだけで進むかもしれません。

ChatGPTとの対話で整理したいのは、この問題の内訳と、必要な情報です。

いまの制作依頼を、依頼内容、担当、最新版、確認待ち、期限に分ける。資料にない情報は推測で埋めず、確認する質問として残す。新しいシステムの提案より先に、既存の道具で解決できる案を比較する。

その結果、まず一件だけを整理して、担当者が次に何をすればよいか分かるか確認します。

必要な情報がそろっていないなら、アプリを作っても空欄は残ります。問題を整理する仕事と、画面を作る仕事を分けることが大切です。

この段階で意味のある完成物は、立派な企画書ではなく、担当者が使える依頼の一件です。僕は、その単位から考えたいと思っています。

15｜具体例：「管理が大変」を、小さな改善へ落とす

制作依頼の管理が大変だという、架空のチームを考えます。これは実装済みの自社システムの説明ではなく、考える順番を示す例です。

依頼は複数の場所に届き、資料の置き場所がばらばらです。担当者は進行中だと言っていますが、依頼した人には、素材待ちなのか確認待ちなのかが見えません。

ここで僕なら、すぐに新しいアプリを作る話へ進めません。まず、いまの一件を取り上げます。依頼が来てから完成するまで、誰が何を受け取り、どこで止まったかを確認します。

その結果、必要な情報の欄がないことが主な原因なら、既存の表に受付条件をそろえる案があります。状態の言葉が曖昧なら、制作中、素材待ち、確認待ちなどを分ける案があります。複数箇所を見なければ進捗が分からないなら、参照先を一つにまとめる案も考えられます。

最初の成果物は、必ずしもコードではありません。「一件の仕事を説明できる表」でも、改善の出発点になります。

そのうえで、繰り返す入力や確認を仕組みにする意味があるなら、実装の条件を整理します。

つくれるからつくるのではなく、何を良くするためにつくるかを決める。経営と実務の立場から、ChatGPTで考えることとCodexへ渡す仕事をつなぎたいと思っています。

16｜ChatGPTで考える仕事と、Codexへ渡す仕事をつなぐ

Gt.OnはChatGPTとCodexを中心に扱います。ただし、二つを必ず順番に使わなければならない、と決めたいわけではありません。

僕が考えるのは、いま必要な完成物が何かです。比較表や依頼文で十分なら、その仕事を終える。実際に動く機能や既存コードの変更が必要なら、実装する工程を考える。

Codexに関するOpenAIの公式案内では、コードの理解や作成、変更、レビューなどの開発作業が扱われています。具体的な利用環境や機能は、最新の公式案内で確認する方針です。OpenAI公式：開発・Codex関連ドキュメント

さきほどの架空の制作チームで、本当に小さな管理画面が必要だと判断したなら、対話で決めた内容を実装の依頼へ変えます。

誰が使うか。必要な項目は何か。どの状態を一覧で分けたいか。今回は何を作らないか。テストにはどんな架空データを使うか。公開や既存データの変更をどこで止めるか。

AIどうしに長い会話をそのまま渡すだけでなく、確定した要求を短く整理する。検討案と採用案を分け、変更してよい範囲を伝える。

相談の勢いを、勝手な実装へ変えない。決めたことを、確認できる依頼へ変える。

その受け渡しを、Gt.Onで深く扱っていきます。

対話から実装へ渡す、一枚の仕事の定義

さきほどの架空の制作チームなら、僕は次のような内容を、実装する前の共通理解として残したいと思っています。これは個別の機能が必ず実現できるという約束ではなく、何を作る話かを確かめる例です。

項目	依頼として渡す内容
使う人	制作依頼を確認し、次の担当を判断する人
今の困りごと	依頼、最新版、確認待ちが別の場所にある
今回の目的	一件の依頼について、誰が次に何をするか分かる
最初の完成物	架空データを使った小さな試作と、確認した操作の記録
今回しないこと	実顧客データの取り込み、外部送信、既存資料の置き換え
判断が必要なこと	担当の決め方、閲覧範囲、正式な保存先
確認する場面	情報がそろう場合だけでなく、担当未定・期限未定の場合も見る

この一枚があると、途中で「便利そうだから」と機能を追加したくなっても、今回の目的に戻れます。話し合いが進んで条件が変わったときも、どこを変更したのかが分かります。

良い対話の価値を、その場の納得感だけで終えない。作る人が依頼を理解し、確認する人が完成を判断できる形まで残す。それが、ChatGPTとCodexを仕事でつなげるうえで、僕が深く伝えたいことです。

17｜実装へ渡すのは、会話の全文よりも確定した条件

相談を重ねた後、すべての会話をそのまま実装担当へ渡しても、何が現在の決定か分かりにくいことがあります。

僕なら、目的、使う人、対象の作業、必要な入力、期待する出力、今回行わないこと、確認する方法をまとめます。

先ほどの架空例なら、まず依頼を一覧にし、素材待ちと確認待ちを区別できるところまでを試す、と範囲を絞れます。自動で顧客へ連絡する機能や、既存データの全面移行は、この試作には含めないと決めることもできます。

そうすれば、実装担当はどこまで作ればよいかを理解できます。確認する側も、関係のない機能を増やすより、今回の作業が進むかを見ることに集中できます。

また、分からないことを要件のように書かないようにします。利用する人の権限や、保存する情報が未確定なら、その確認を先に残します。

会話で考えたことを、実装で迷わない条件へ変える。この受け渡しまで含めて、AIを実務へ使う力だと考えています。

Codexへつなぐ前に、何のための仕組みかを説明する

開発に関わる仕事では、便利そうな画面の案を考えるだけでなく、どの人が、どの場面で、何をできるようになる必要があるかを整理したいと思っています。

依頼を管理したいなら、単に一覧を表示すればよいのか、同じ依頼の重複を見つけたいのか、担当が決まっていない仕事を確認したいのかで、必要なものは違います。全部入りの仕組みを最初に目指すより、一つの困りごとから判断することを大切にします。

そのうえで、今の表や手順を変えるだけで足りるかも考えます。新しく開発することだけが前進ではありません。既存の運用に担当や状態の記入欄を足せば進むなら、その案も比較対象です。

本当に開発へ進むなら、何を入力し、何を表示し、何を保存し、どんな場合に止めるかを、実装する人が判断できる言葉で渡します。実際の顧客情報を使う前に、どんな検証が必要かも分けます。

僕は、開発の専門家の仕事を軽く見せたいわけではありません。AIで作れる可能性が広がっても、目的の理解、検証、維持、権限の判断が不要になるとは考えていません。必要な専門性を尊重しながら、事業の側が責任を持つべき前提を明確にする。その役割を果たせる経営者でありたいと思っています。

18｜長い相談を、次の担当者が着手できる一枚へ変える

対話が長くなるほど、よい案だけでなく、採用しなかった案や途中で変わった条件も増えます。僕は、その会話を全部渡せば、次の担当者が同じ理解になるとは考えていません。

ここでは、制作依頼を整理する小さな管理画面を考える、架空の相談を例にします。既存の一覧表は残し、依頼内容と状態を見やすくしたい。今回はテスト用データの試作までで、実顧客の情報移行や通知は行わない、という条件です。

完成させるものを、機能の名前より先に書く

僕なら、次のような一枚へまとめて渡します。

目的： 制作担当者が、各依頼で次に確認することを見つけられる試作を作る。

入力： 架空の依頼名、現在の状態、確認事項、担当の欄を持つテストデータ。

完成物： 一覧と一件の詳細を確認できる試作画面。

固定すること： 既存の管理表とその内容は変更しない。

今回は行わないこと： 実顧客データの読込み、外部への送信、権限の本番変更、課金。

確認すること： 同じ依頼が一覧と詳細で一致し、状態と確認事項が読めるか。保存機能を作る場合は、再表示で内容が残るかを別に確認する。

残る判断： 本番に必要な閲覧範囲、更新の担当、既存表との関係は別途決める。

これは、実装へ渡す条件の架空例です。実際のツールでこの機能が作成済みという意味ではありません。

未確定を、実装担当の想像で埋めさせない

例えば、担当者がいない依頼を誰へ割り当てるか決まっていないなら、勝手に自動割当てを追加してもらうのではなく、未割当てが分かる表示までにします。通知が必要か不明なら、実際の送信先を作らず、確認が必要な仕様として残します。

その代わり、着手に足りる確定事項は具体的に渡します。「いい感じの管理画面」ではなく、誰がどの場面で何を判断するかが分かる依頼にするためです。

実装から返ってきたら、この一枚と照合します。画面ができたかだけでなく、今回は行わないと決めたことをしていないかも確認します。

長い会話を短くするためではなく、次の仕事を正しく始めるために整理する。僕は、その受け渡しもAIを使う仕事の重要な部分だと考えています。

19｜実装へ進めるなら、「やらないこと」も決める

架空の制作管理画面を考える場合、最初から通知、請求、顧客管理、投稿連携まで作る必要はないかもしれません。

僕なら、今回解決する一件を絞ります。担当と確認待ちの状態を表示できることが目的なら、そこに必要な項目と操作を先に決めます。

また、実際の顧客データを入れる前に、説明用のデータで確認する工程を考えます。誰が見られるか、どこが変更されるか、入力を間違えたときどうなるか。画面の見た目以外の条件も扱います。

「動くものを作って」という指示だけでは、完成の意味が広すぎます。入力できる、保存できる、表示できる、担当者が理解できる。それぞれを確認する必要があります。

そして、作ったあとに直す人のために、変更の理由や確認した範囲を残します。コードがあることと、仕事として使い続けられることを分けるのです。

僕は、AIを使うことで実装の入口が近づくほど、何を実装するかを考える力が大切になると思っています。

20｜AIの「完了」を、仕事の完了と同じにしない

返答が終わった。ファイルができた。実行したと報告があった。その言葉だけで、今回の仕事が使える状態になったとは判断しません。

僕なら、成果物を開きます。必要な内容があるか。指定した形式か。リンクや表が使えるか。何かを更新する仕事なら、保存先で実際に変わった内容を確認します。

コードなら、どのテストを行ったか、結果は何か、まだ確認していないことは何かを分けます。テストの成功が、事業上の効果まで証明するわけではありません。

文章でも、誤字がないことと、読者へ正しく伝わることは別です。資料の完成と、相手の意思決定が進んだことも分けます。

こうした確認は、AIを信用しないためではなく、仕事を信用できる状態にするためです。

提案した、つくった、動かした、確認した、公開した。

この違いを言葉にできれば、次の担当者も何をすればよいか分かります。Gt.Onでは、便利な出力と、確認された結果を混同しない説明を大切にします。

21｜完了報告には、実物と確認の範囲を添える

「完成しました」という言葉は、何が完成したかと一緒に伝えたいと思っています。

文章ができたのか、画面が表示されたのか、入力した情報を保存できたのか、実際の利用環境で確認できたのか。段階を分けます。

例えば、画面の試作なら、表示できたことを報告できます。ただし、データ保存を確認していなければ、その点は未確認とします。ローカルで操作したなら、公開環境でも動くと決めつけません。

僕が受け取りたい報告は、何を作り、どこにあり、何を試し、何が分かり、次に何を確認するかが見えるものです。

これは、成果を小さく見せるためではありません。次の人が安全に仕事を引き継ぎ、必要な判断をできるようにするためです。

AIが出した報告でも、人が書いた報告でも同じ基準で見たい。実物と説明が対応していれば、使う側も安心して次の仕事を選べます。

できたことを正しく伝える力も、仕事を完成させる力の一部。Gt.Onでは、その確認と受け渡しまでを具体化していきます。

22｜「作りました」と「使えます」の間を、証拠でつなぐ

僕がAIと仕事を進めるとき、最後に大切にしたいのは、完了という言葉の強さより、何を確認できたかです。

ここでは、説明用に架空の文書作成を考えます。依頼は、通常の編集画面へ貼り付けて修正できる案内文を作ることでした。返ってきたのは、見た目の整ったページのスクリーンショットだけだったとします。

この場合、見た目がよいことは確認できても、文章として編集できる状態かは分かりません。頼まれた完成物と、返された完成物が違うからです。

受け取る人の操作から、確認を考える

僕なら、本文を選べるか、コピーできるか、必要な見出しや段落が残るか、目的の編集欄へ貼り付けた後に文字を変更できるかを、確認できる範囲で見ます。

ファイルがあることと、リンクから開けることも分けます。自分の画面で読めたことと、相手の使用環境で使えたことも分けます。確認していない環境まで、「どこでもそのまま使える」と報告しないようにします。

案内文の本文と、見出し付きの表示は作成しました。ローカルの確認環境では、本文のコピーと貼り付け後の編集を確認しています。実際に利用するサイトへの保存と公開はまだ行っていません。公開先での確認に必要な文章と、残る項目を分けてお渡しします。

これは、確認の範囲を示す架空の報告例です。今回の成果物が実際にどこまで検査済みかは、その成果物自身の検査記録で確認します。

次の人へ、未完了を押し付けるための説明にはしない

未確認を示すだけで終わらず、自分が行える確認は行います。そのうえで、権限や環境の違いによって残ることを特定します。相手に頼む必要があるなら、「何を開き、どの表示を確認すればよいか」まで具体的にします。

不具合が見つかった場合には、修正前の説明を残したまま完了と言い続けず、どこが変わり、どこを再確認したかを更新します。

僕が目指すのは、立派な完了報告を作ることではありません。受け取った人が、次の作業を無理なく始められることです。

できたことを大きく言うより、できたことを実際に渡す。Gt.Onでは、その実行と説明の一致を大切にしていきたいと思っています。

完了の報告は、期待ではなく確認できた状態で書きたい

仕事を依頼した後に知りたいのは、頑張ったことだけではありません。何が使える状態になり、何を確かめ、次に何が残っているかです。

僕自身も、成果物について説明するとき、作成、保存、表示、動作確認、公開を分けたいと思っています。原稿を書いたなら、書いたことを伝える。編集できる形式まで確認したなら、その範囲を伝える。実際の公開先を見ていないなら、見ていないことを残します。

全部を完了したように言えば、受け取る人は追加確認が要らないと考えてしまうかもしれません。それは、後で人が困る原因になります。逆に、残っていることばかりを大きくして、すでに使えるものまで分からなくする必要もありません。

できたものと、まだできていないことを、同じ報告の中で具体的に示す。次に必要な入力や判断があれば、その担当と対象を示す。僕は、その報告が実務を前へ進めると思っています。

完了を大きく見せるより、受け取った人が安心して次の仕事を始められるようにする。これはAIの出力だけでなく、人へ仕事を任せ、受け取り、引き継ぐときにも大切にしたい基準です。

23｜「全部任せたい」という相談を、最初の一つへ絞る対話

Gt.Onで僕が伝えたいのは、指示文の形だけではなく、仕事の問いをつくる過程です。以下の会社、依頼、会話は説明用の架空例で、実際の開発や導入の成果ではありません。

相談は「制作依頼がいろいろな場所に来て管理が大変なので、AIで全部自動化したい」です。この段階では、何が一番困るのか、どこまで任せてよいかが分かりません。

僕なら、次のように会話を進めたいと思います。

相談者： 制作依頼を全部、自動で管理したいです。

返す問い： 最近、一件の依頼がどこで止まったかを教えてください。連絡を見失ったのか、内容が分からなかったのか、担当が決まらなかったのかを分けたいです。

相談者： 同じ依頼が二か所に来て、別々の人が作り始めました。

返す説明： 今回最初に解きたいのは、すべての制作の自動化ではなく、同じ依頼だと分かることと、担当が決まる前に重複して着手しないことですね。

この整理ができれば、いきなり大きなアプリを作る前に、既存の表へ依頼の識別欄と担当の確認欄を足す案も比較できます。

本人が望んだ「全部自動化」を否定するのではありません。その先にある問題を、一件の仕事から理解したいのです。

曖昧な相談を、すぐ大きな制作へ変えない。まず、何が起きたら前に進んだと言えるかを言葉にする。この対話の力を、AIと仕事をする人へ伝えたいと思っています。

24｜会話の全文ではなく、決まった条件を一枚にする

制作依頼の重複を防ぐ架空例を、実装する人へ渡す段階まで進めます。次の文章は、試作について相談するための記入例です。実際に動く機能を提供したという報告ではありません。

目的： 同じ依頼が複数の入口から届いても、別々の仕事として着手しないようにする。

今回の利用者： 依頼を確認する担当者と、制作を担当する人。

扱う情報： 依頼を区別する番号、件名、元の連絡場所、確認した担当、進行の状態。試作では架空データだけを使う。

最初に確かめること： 既存の管理表への項目追加で足りるか。

画面を試作する場合： 一覧、内容確認、同じ依頼かを人が確認する表示を候補にする。

今回しないこと： 顧客への自動返信、本番データの変更、担当者への自動割当て、課金や契約の変更。

人が決めること： 二件が本当に同じ依頼か、どちらを正しい記録として扱うか、誰が着手するか。

この例では、AIへ任せる目的が、人物の判断や外部への連絡まで勝手に広がらないようにしています。

重要なのは、会話の中に出た案を全部含めることではありません。選んだ案、選ばなかった案、まだ確認が必要なことを分けることです。何度も話し合った末の結論でも、最終的に残る条件は読み取れる形にする必要があります。

僕は、AIとの長いやり取りをしたこと自体を、実装準備ができた証拠にはしたくありません。受け取った人が「今回何をつくり、何には触らないか」を説明できるところまで具体化したいと思っています。

25｜動く画面ができた後、正常な一回だけで確認を終えない

前の架空例で、制作依頼を一覧にする試作画面ができたと仮定します。ここからも、実際のテスト結果ではなく、僕が確認したい条件の例です。

確かめる場面	この試作で期待する扱い
新しい依頼を一件受け取る	依頼を区別する情報と状態が見える
同じ識別番号の依頼をもう一度入れる	新しい仕事として黙って増やさず、重複を確認できる
件名が似ている別依頼を入れる	類似だけを理由に自動で一件へまとめない
必要な入力が空欄	作成できたように見せず、何が不足しているかを示す
保存が失敗する	保存済みと表示せず、再確認できる状態にする
担当が未確定	誰かが引き受けたことにせず、未確定のまま残す

ここで示す期待は、要件として選んだものです。表を書いたことと、そのとおりに実装されたことは別です。実際の画面で入力し、出力と保存状態を確認する必要があります。

また、見た目が整っていること、処理が動くこと、実際の仕事に使えることも同一ではありません。担当者がどちらの依頼を残すか迷うなら、表示の説明が不足している可能性があります。仕組みが動いても、管理する場所が増えただけなら、本来の負担は減らないかもしれません。

だから、試作の意味は動くものを見せることだけではありません。仕事の条件を、実物に触れながら確かめ直すこと。僕は、AIによる制作や開発を、その判断の機会としても使いたいと思っています。

26｜完了報告には、やっていないことも同じ明確さで書く

架空の試作を担当した人やAIから「完成しました」と返ってきたとき、僕は何を完成と呼んでいるかを確認します。コードを書いたのか、画面を開いたのか、入力と保存を試したのか、本番で使えると確認したのか。それぞれ違う状態です。

返してほしい報告は、例えば次のような形です。これは報告の文案であり、この例の試作が実際に完成したという事実ではありません。

作ったもの： 架空の依頼データを扱う一覧と確認画面の試作。

確認したこと： 実際に試した入力と、得られた結果を項目別に記載する。

確認していないこと： 本番データ、複数人での同時利用、権限の設定、外部への通知。

行っていない操作： 本番への公開、顧客への送信、既存記録の変更。

次に必要な判断： 既存の表で対応する案と比べ、試作をさらに進める理由があるかを決める。

「確認したこと」の欄へ、実行していないテストを埋めないことが前提です。未実施が残っていても、現在地が分かれば次を決められます。

僕は、AIが自信を持って報告したことを、そのまま経営の事実として採用したくありません。実物と確認した範囲を受け取り、その先の判断を自分の言葉で持ちたいと思っています。

対話から始まった仕事を、誰かが使える形へ進める。その過程で、問い、選択、実装、確認を混ぜない。Gt.Onで届けたいのは、そうした一連の仕事を自分で進めるための考え方です。

27｜一つの相談を、繰り返し使える知識へ変える

良い会話ができたとしても、その後に同じ説明を一から繰り返しているなら、残し方を考えたいと思っています。

僕なら、採用した方針、使った材料、作った成果物、未解決のこと、次の作業をまとめます。対話の全部を読み返さなくても、再開できる記録にするためです。

特に、複数の仕事が進む場合には、顧客や事業ごとの前提を混ぜないことが大切です。ある会社で承認された表現を、別の会社でも使えると思い込まない。仮の企画を、実際の商品条件へ混ぜない。

ChatGPTのプロジェクトなどの整理機能を使う場合も、何を入れるかは人が考えます。機能があることと、資料が整理されていることは別です。OpenAI公式：プロジェクト

情報が古くなったとき、どこを更新するかも決めたい。会話の中の古い前提が、そのまま新しい成果物へ戻ってこないようにします。

僕が育てたいのは、長い会話を続ける技術だけではありません。会話から仕事の知識を取り出し、次に使える状態へする力です。

複数の人やAIが関わっても、最後の責任を見失わない

一つの仕事に複数の道具や担当者が関わると、それぞれの処理は進んでいても、全体として何が終わったかが分かりにくくなることがあります。

調べる担当は資料を集めた。書く担当は原稿を作った。制作する担当は見た目を整えた。それでも、使う資料が違っていたり、どの版を公開するか決まっていなかったりすれば、受け取る人が使える状態にはなっていません。

僕は、このつながりを見たいと思っています。どの情報を使い、何を次へ渡し、誰がその内容を確認するのか。受け渡しの途中で、不明なことが勝手に確定へ変わらないか。最終的な版がどれか分かるか。

これは、たくさん連携すればよいという話ではありません。必要な工程だけをつなぎ、重複している仕事や、責任が曖昧な部分を減らすことが目的です。連携した数ではなく、次の担当が迷わず動けるかを考えます。

代表として自分がすべての処理を行う必要はなくても、事業の目的と公開の責任まで分散して見えなくなる状態は避けたい。誰が何を確かめたかを理解できる形で、専門家やAIと仕事を進めたいと思っています。

28｜相談から生まれた判断を、自分の言葉で残す

役立つ回答が得られたとき、僕は、長い返答を丸ごと保存するだけではなく、今回何を採用したかを一文にしたいと思っています。

何を目的に、どの案を、どんな条件で選んだか。なぜ別の案を見送ったか。どんなことが分かれば見直すか。

この記録があれば、同じような相談が来たときに、答えを探し直すだけでなく、過去の判断を材料にできます。

ただし、条件が違うときには、その記録をそのまま正解として使いません。相手、素材、目的、時間が変わったら、どこを考え直すかを見ます。

僕が教育で目指しているのも、見本の再生ではなく、理由を理解して使うことです。AIとの対話も、考えた記録が次の自分や他の人の学びになるようにしたい。

良い回答を集めるだけでなく、自分が選んだ理由を積み重ねる。その使い方なら、AIとの会話が、自分の仕事を理解する時間になります。

29｜AIと考えても、最終的に選ぶ理由は自分の言葉で持つ

複数の案を出してもらうと、どれもそれらしく見えることがあります。そんなとき、僕はAIの推薦文の強さだけで選びたくありません。

今回の目的に近いか。使える材料で実行できるか。相手へ約束できる内容か。ほかの仕事への負担はどうか。あとから見直せるか。

選ぶ基準を明らかにし、その基準に照らして決めます。

たとえば、目新しい企画でも素材がなければ今は保留にできます。大きな自動化案でも、少量の仕事なら手作業を選べます。文章が美しくても、本人の経験と違うなら直します。

その判断を説明できれば、別の条件になったときも考え直しやすくなります。

AIを活用することと、自分で判断することは対立しません。むしろ、比較する材料を増やしながら、自分の責任を明らかにする使い方をしたいと思っています。

「AIがこう言ったから」ではなく、「この目的と条件に合うから採用した」と言えること。その状態を、僕は目指しています。

採用した理由だけでなく、考え直す条件も残す

自分の案に納得した後も、「どんなことが分かれば、この判断を変えるか」を考えておきたいと思っています。

既存の表を直す案を採ったとして、実際に担当者が使うと確認の場所が増えてしまうなら、設計を見直す理由になります。試作した画面が便利でも、更新を続ける負担が見合わないなら、別の方法へ戻す選択肢があります。

AIとの対話で一度合意したことを、正解として守り続ける必要はありません。目的に近づくために選んだ方法なら、目的とのずれが分かったときに変えてよい。

僕は、AIに自信を補ってもらうだけでなく、自分の判断を更新できるように使いたいのです。その使い方なら、最初の案が違っていても、対話と実践を続ける意味が残ります。

一度選んだ案を、考え直せる記録にしておく

僕は、意思決定を、その時点で正しい答えを言い切ることだけだとは考えていません。今ある材料から選び、後で新しいことが分かったら、理由を持って変えられることも含めたいと思っています。

そのために、案を採用したときの前提を残します。使える素材がこれだけだった。担当できる人が限られていた。今回は文章で試せる範囲を優先した。そうした条件が分かれば、後から状況が変わったときに、どこを見直すかも明確になります。

結果が期待と違ったときにも、単に最初の案を責めるだけにしません。前提が変わったのか、見落としていたことがあったのか、実行した内容が違ったのかを分けます。良い結果だったときも、理由を一つに決めつけず、次へ使える範囲を考えます。

AIとの対話では、もっともらしい説明が後からいくらでも作れるように感じる場面があります。だからこそ、選ぶ前に何を期待し、何を見るつもりだったかを残したい。その記録が、自分の判断を都合よく書き換えないための材料になります。

僕がGt.Onで伝えたいのは、自信のある言葉を出す技術だけではありません。判断を更新しながら、仕事を続ける技術です。一回の返答を正解として固定せず、現実の結果へ戻れる使い方を深めていきます。

30｜人の経験を、AIの一般論で塗りつぶさない

僕はSNS教育の立場から、本人が持っている経験を大切にしたいと思っています。

何を試したか。何で迷ったか。どんな失敗を避けたいか。誰からどんな質問を受けたか。その情報があるから、読者に届く具体的な話ができます。

ChatGPTを使うときにも、先に立派な文章を作って、それに自分を合わせる順番にはしたくありません。

まず経験を整理する。起きたことと感想を分ける。確認できた変化と、原因についての考えを分ける。読者が使える判断を一つ取り出す。

そのうえで、構成や表現を手伝ってもらいます。足りない経験を、自然な物語として補わせないようにします。

僕が考える独自性は、誰とも違う言い回しを探すことだけではありません。自分が持つ材料と、相手の具体的な疑問をつなぐことです。

AIとの対話によって、自分の中にある材料へ気づける。その可能性を、Gt.Onでは深めていきたいと思っています。

31｜教育では、答えより先に「どこで止まったか」を見る

S.Lineでは、Instagram教育のS.Tep、SNS運用代行者育成のSkill.Onなどを展開しています。教育事業の案内

僕は、その教育とAI活用をつなげて考えています。ただし、質問にすぐ答えられるようになったから、学習が完成するわけではありません。

説明が分からないのか。手順が分からないのか。選択肢が多くて選べないのか。実物を作った後に、良し悪しを判断できないのか。

止まっている場所が違えば、必要な支援も変わります。

AIに全部の完成物を作ってもらうことより、本人が次の一部分を作れるようにする。答えと違う箇所を探すより、条件に合う理由を説明できるようにする。その使い方を大切にしたいと思っています。

自分で考えることを守るために、AIを使わないと決める必要はありません。どこを自分が行い、どこを助けてもらい、何を理解できたかを分ければよいのです。

僕がGt.Onを通して増やしたいのは、AIへ依存する質問の数ではなく、本人が説明できる仕事です。

32｜学習では、本人が考えた部分が見えるようにする

AIの支援があると、整った成果物が得られることがあります。ただ、学ぶ目的なら、本人がどの判断をできるようになったかも見たいと思います。

自分の初案、AIの候補、採用した部分、修正した部分を分ける。なぜその案を選んだかを、自分の言葉で説明する。別の条件でも、考え直せるかを試す。

こうした過程が残れば、支援を使うことと本人の成長を両立できます。

僕は、AIを使ったから学んでいないと決めつけたくありません。一方、出力が立派だから理解できたとも決めません。

本人が困っていることに合わせて、質問だけを返す場面、ヒントを渡す場面、見本で比べる場面を分けたいと思っています。最初から全部の答えを渡すのではなく、必要な支援で一歩を進める。

教育のためにAIを使うときにも、学ぶ人の判断を主役にする。その方向を、Gt.Onで発信していきたいと考えています。

AIを学ぶ人が、自分の言葉を持ち続けられるように

僕が将来も関わりたいのは、人が自分の可能性を見つける教育です。子どもたちの未来に関わる教育にも、いつか取り組みたいと考えています。その形はまだ決め切っていませんが、今の仕事でも、人が考える力をどう残すかは大切な問いです。

便利な答えを受け取れることは、取り組む入口を広げます。一方で、答えを読んだだけで理解したことにすると、自分の状況が変わったときに使えなくなります。だから、採用する理由を自分の言葉で説明することを大切にしたいと思っています。

何を助けてもらい、どこを自分で判断したかが分かること。分からないときには、もう一度資料へ戻ったり、人へ相談したりできること。AIを使わないと何も選べない状態ではなく、AIを使うほど、自分の問いが具体的になる状態を目指します。

これは、AIから距離を置くための教育ではありません。使う力を、操作だけではなく、判断と責任まで含めて育てるための教育です。僕自身も、自分の仕事の中で、その境界を学び直していきたいと思っています。

33｜費用や機能の比較も、「何に使うか」へ戻す

ChatGPTやCodexの情報を調べるとき、モデル名やプランの違いは気になると思います。

僕は、それらを知ることと、自分に必要な選択をすることをつなげたいと考えています。

何をどれくらい行うのか。どんな入力を使うのか。どの品質で完成とするのか。人の確認にどれくらい負担があるか。そこがないまま、上位のものを選べば仕事が解決するとは説明しません。

また、アプリとして使う場合と、APIを用いて開発する場合など、利用の入口が異なる話は分けます。料金、認証、管理、実行環境が関係する内容は、その製品の最新の公式案内で確かめます。

本プロフィールには、変わりやすいモデルの順位や固定の利用上限を並べません。Gt.Onの記事で具体的な数値を扱う場合に、確認した時点と対象を示す方針です。

僕が届けたいのは、最新の名前を知っている安心ではなく、今の仕事に必要な機能と条件が分かる安心です。

34｜Gt.Onで、これから深く伝えること

ChatGPTの基本的な使い方では、質問の書き方だけでなく、前提のそろえ方、材料の渡し方、返答の確認を扱います。

調査や企画では、何を決めたいかを定義し、複数案を比べ、根拠と不明点を残す過程を示します。情報を集めるだけで終わらない使い方です。

文書、画像、資料などの制作では、本人の経験や顧客の事実を守りながら、完成物へ変える方法を扱います。出力の美しさと、使ってよい内容かを分けて確認します。

Codexや開発に関する記事では、何を実装するか、どこまで任せるか、何をテストするか、どう引き継ぐかを扱います。動作したという説明と、確認できた結果を分けます。

そして、対話を続ける仕事では、決定事項や成果物をどう残すかを考えます。翌日も、別の人も、必要な前提から再開できる状態を目指します。

35｜相談の質を、日々の仕事の中で少しずつ上げる

ChatGPTやCodexに詳しい人だけが、このメディアの対象ではありません。

頭の中の課題を整理したい人。依頼文を具体的にしたい人。比較して決めるための資料が欲しい人。実際に作ったものが、使える状態か確認したい人。そうした仕事の場面から、必要な使い方を届けたいと思っています。

最初は「何が分からないか分からない」でも構いません。会話の後に、問いが一つ具体的になる。次は使う材料をそろえられる。その次は、完成の条件を説明できる。

その積み重ねは、AIへ依頼するときだけでなく、人へ仕事を渡すときにも役立ちます。

僕がGt.Onで伝えたいのは、特殊な言い回しを知っている人だけが得をする世界ではありません。自分の目的と材料を言葉にできるほど、道具を仕事へ使いやすくなるという考え方です。

対話で整理し、実物で確かめ、自分の判断として残す。その一周を、読者が自分の仕事でできるように支えていきます。

Gt.Onを読んだ後に、どんな一歩が残ってほしいか

このメディアを読んだ人に、毎回新しいツールへ登録してほしいわけではありません。いま困っている仕事を一つ開いて、何を決めたいのかが前より説明しやすくなるだけでも、意味のある一歩だと考えています。

資料を集める前に、何を知るための調査かが決まった。長い会話から、採用した内容を一枚にできた。案に賛成することと、外へ出してよいことを分けられた。作ったものについて、確認済みの範囲を報告できた。そうした小さな変化を、実際の仕事へ積み重ねてほしいと思っています。

僕は、読者の代わりに人生や事業の答えを決める人でありたいわけではありません。読者が自分の材料を整理し、必要な支援を使い、自分の選択を説明できるようになる情報を届けたいのです。

そのために、ChatGPTやCodexの話題を、単発の便利さで終わらせません。考えるところから、作り、確かめ、次へ渡すところまでつなぎます。実際の仕様や条件はその時点で確認し、変わらず使える考え方と分けて伝える方針です。

答えを手に入れることから、自分で次の仕事をつくれることへ。その移行を支えるメディアとして、Gt.Onを育てていきたいと思っています。

36｜公式情報と、自分たちの見解を分けるメディアへ

Gt.Onの運営会社は株式会社S.Lineです。OpenAIの公式メディアや、公認された代表者として発信するものではありません。

製品の機能や条件についてはOpenAIの公式情報を確認し、そこに書かれた内容と、僕たちが実際に試した内容、実務上の解釈を分ける方針です。

未検証の手順を検証済みと表示せず、説明用の例を導入実績として見せません。使った環境や対象が限られる場合は、その範囲を明らかにします。

記事ごとの執筆・編集・監修も、実際の関与に合わせて表示します。すべてを僕が直接実装・検証したという肩書きの使い方はしません。

自社サービスや広告、提供、紹介による報酬などが関係する場合は、読者がその関係を理解できる表示を行う方針です。

最新情報を扱うときにも、変化への不安だけで行動を急がせたくありません。今の仕事に関係するか、すぐ変える必要があるかを判断できる説明にしていきます。

37｜AIとの対話から仕事へ進むとき、先に考えたい四つの問い

何を聞けばよいか分からない人にも、AIとの対話は使えるか

最初から整理された問いだけを用意する必要はないと思っています。最近困った一件を説明し、どこで止まったかを分けるところから始められます。

ただし、AIが提案した問題の捉え方を、すぐに事実として採用しません。自分が確認できる情報へ戻り、本当にその場面で困っているかを見ます。曖昧な相談を責めず、曖昧さを少しずつ具体的な確認へ変える。その使い方を、教育の視点から伝えたいと考えています。

反対意見を出してもらえば、判断は客観的になるのか

それだけでは決まりません。反対意見も、前提と根拠を確認する候補です。今回の条件には当てはまらない一般論かもしれませんし、実際には重要な負担を指摘しているかもしれません。

僕は、賛成か反対かより、何の条件が判断を変えるかを知りたいと思っています。その条件を確かめられるなら、調べる仕事へ戻します。分からないままなら、その不確かさを含めて案を比較する。対話の形式だけで、現実の確認を済ませたことにはしません。

自動化したいという相談を、手作業の改善へ戻すこともあるか

あります。現在困っているのが、担当が未定なことや、同じ依頼が二重に記録されることなら、最初に決めるルールや記録項目が必要かもしれません。

その整理なしに新しい画面を作っても、迷いが別の場所へ移るだけになる可能性があります。手作業を続ける案、既存の道具を直す案、小さく開発する案を比較したいと思っています。開発しない判断も、目的に合うなら前進です。

長く相談したのに、何も始められないときはどうするか

会話の全文を増やす前に、次に一人が始められる仕事へ戻したいと思っています。何を作るか、使う材料はどれか、誰に確認するか、今回は何をしないかを一枚へ整理します。

足りないものがあるなら、その確認を最初の仕事にします。すべての不確実性が消えるまで待つのではなく、今進めてよい範囲を選ぶ。その後、できたものと確認した範囲を記録すれば、次の会話はそこから始められます。対話を、実際に残る仕事へつなげる使い方です。

38｜最初の相談を、できることの一覧へ急いで置き換えない

AIへ相談するとき、本人が欲しいものを最初から明確に言えるとは限りません。「仕事をもっと楽にしたい」「発信を良くしたい」「資料を分かりやすくしたい」。その言葉の中には、別々の困りごとが含まれています。僕は、すぐにできることの一覧を返すより、本人がどの場面で止まっているかを一緒に整理する対話を大切にしたいと思っています。

例えば、説明用の架空例として「会議を減らしたい」という相談を考えます。会議の回数が多いのか、決める人がいないのか、会議後に同じ説明を繰り返しているのかで、必要な改善は違います。要約を作れば解決すると先に決めるのではなく、直近の一件で何が決まり、何が残ったかへ戻ります。

僕なら、「会議を終えた後、誰が何を始める予定でしたか」「実際にはどこで止まりましたか」「決まっていなかった条件は何ですか」と問いを分けます。これは実際の取材会話ではなく、相談を具体化するための文例です。本人が説明しきれない状態を、準備不足として終わらせず、必要な情報を見つける過程として扱いたいのです。

ここで得た答えが「担当が決まらず、全員が待っていた」なら、最初の課題は議事録の長さではないかもしれません。担当を決める人、引き受ける条件、次に確認することを整理する。そのうえで、AIが要約や確認事項の抽出を助ける余地があるかを考えます。道具の得意な仕事へ、相談の内容を無理に合わせません。

本人が欲しいと言った形を尊重しながら、本当に進めたい仕事を一緒に見つける。Gt.Onでは、AIへの頼み方を、上手な命令文だけの話にしたくありません。相談の入口から目的が具体化するまでにも、人の判断を助ける価値があると考えています。

39｜長い対話から、次の人に渡せる一枚を取り出す

対話を重ねると、選んだ案、見送った案、途中で変わった条件が一つの会話に積み重なります。僕は、その長さ自体を深く考えた証拠にはしたくありません。次の人が会話を全部読み直さないと動けないなら、仕事として残す形を見直す必要があるからです。

僕が取り出したいのは、目的、現在の決定、使う材料、しないこと、残る確認、次の担当です。「何を検討したか」の一覧だけでなく、「今はどの案で進み、何がまだ未定か」が分かる一枚にします。途中で捨てた案を、現在の依頼へ混ぜないことも重要です。対話の要約と、実行の依頼書は用途が違います。

説明用の架空例として、制作依頼を整理する仕組みを考えた場合、「同じ依頼に二人が別々に着手しないようにする」が目的だとします。現在は既存の管理表を見直す案を選び、新しいシステムの制作はまだ決めていない。その状態なら、次に渡す文章も「既存表の項目と受付の流れを確認する」であり、「新システムを作って公開する」ではありません。

未確認もそのまま残します。誰が同じ依頼と判断するか未定なら、担当者へ勝手に責任を割り当てません。連携の可否を調べていないなら、できる前提の設計にしません。本人が「良さそう」と言ったことと、外部へ実行してよいと承認したことも分けます。対話を整理するほど、その違いが見える状態にしたいのです。

長く話した価値は、会話の量ではなく、次の人が何を確かめて進めるかに残る。僕は、AIとの対話を自分だけの納得で終えず、顧客、制作担当、開発担当へ正しくつながる仕事にしたいと思っています。資料を渡した後も、相手がどこで判断に迷うかを見て、説明を直していきます。

40｜選んだ案を実行するとき、権限と期待を一緒に広げない

文章で考える段階では、多くの可能性を出せます。しかし、実際のファイルを変更したり、外へ送信したり、人の情報を扱ったりする段階では、進めてよい範囲を明確にする必要があります。僕は、案に賛成したことを、その案に関係するすべての操作への承認へ広げたくありません。

依頼するときには、作るものだけでなく、何をしないかも伝えます。下書きを作るのか、既存の内容を更新するのか、試作品を用意するのか、本番で使う形へ反映するのか。それぞれの違いを、担当者が分かる言葉にします。「進めてください」という短い言葉に、送信、公開、削除まで含まれると推測しないようにしたいのです。

例えば、新しい問い合わせ対応の文案を考える架空例なら、「確認済み資料をもとに文案を作る。現在の回答文は変更しない。顧客へ送信しない。条件にない希望は質問として残す」と整理できます。試作品を作る場合も、使うデータ、触ってよい範囲、完成を確かめる場面を決めます。実際の権限やサービスの仕様は、利用する環境で確認する対象です。

実行した後も、何が変わったかを明らかにします。案ができた、ファイルができた、開いて確認できた、編集できることを確認した、相手へ渡した。その段階を分けて説明すれば、受け取る人がまだ必要な作業を判断できます。自分が確認していないところまで、完了という一語で広げません。

対話で可能性を広げることと、実行できる範囲を広げることは別です。僕は、AIとの仕事でこの境界を具体的に持ちたいと思っています。慎重さのために何もしないのではなく、今進めてよいことを確実に進め、次の承認が必要な部分を分かる形で渡す。その実行力を、Gt.Onで伝えていきます。

41｜出力に納得した後も、自分の判断として説明する

AIから整った提案が返ってくると、その理由を読んだだけで、自分も十分に検討したように感じることがあります。僕は、そこでも一度、自分の言葉へ戻りたいと思っています。なぜ今回この案を選ぶか。何を使い、どこを確かめ、どの負担を引き受けるか。その説明を自分で持てることが、実務で使ううえで大切だと考えています。

採用した理由は、AIが詳しく説明したからではありません。目的に合い、使える材料があり、条件を守れ、確認する方法が見えるからです。反対に、魅力的でも材料がない案、今の体制では続けにくい案、判断に必要な情報が欠ける案は、別の候補として残せます。実行しないことを、発想を無駄にした扱いにはしません。

説明用の簡単な記録なら、「今回は既存の手順を整理する案を選ぶ。新しい仕組みを作る前に、依頼の重複がどこで起きるか確かめられるから。担当者の負担が増えるようなら入力項目を減らし、目的を満たせない場合に次の案を検討する」と書けます。自分の採用理由と、見直す条件が一緒に残る形です。

この記録があれば、結果が違ったときにも自分を守るための説明へ逃げずに済みます。当初の前提が違ったのか、やってみて負担が分かったのか、目的が変わったのかを見直せます。良い結果が出ても、別の条件まで同じ案を正解として広げないようにします。意思決定を、一度で自信を得る行為ではなく、経験から更新できる仕事として扱いたいのです。

AIを使うほど、自分の考えを説明できる範囲が増える。その方向へ進みたいと思っています。僕は、答えを受け取る人を増やすだけでなく、問いをつくり、材料を選び、実物を確かめ、次の一手を決められる人を増やしたい。教育と経営を行う立場として、この対話の先にある力を、Gt.Onから届けていきます。

42｜よくある質問

Gt.Onは、ChatGPTだけの使い方を扱いますか？

ChatGPT・Codexを中心に、対話、調査、制作、開発を仕事につなげるテーマを扱います。製品や利用環境の違いを分け、目的に応じた使い方を説明する方針です。

最初から上手なプロンプトを書く必要がありますか？

僕は、最初の相談が整理されていなくてもよいと考えています。その後の対話で、目的、材料、制約、完成物、確認方法を明確にしていくことを大切にします。

ChatGPTとCodexを必ず一緒に使うべきですか？

そうは考えていません。文章や表で解決するなら、必要以上に開発へ進める必要はありません。実装が必要な仕事かを先に判断します。

このプロフィールがあれば、全記事を岡田颯太が確認しているという意味ですか？

いいえ。記事ごとの著者・編集者・監修者は、実際に関わった範囲に合わせて表示する方針です。運営と個別記事の検証を混同しません。

OpenAIの公式見解として読めますか？

本メディアは株式会社S.Lineが運営する独立した媒体です。公式の製品情報を説明する部分と、僕たちの実務上の意見を分けて発信します。

43｜対話の先に、自分の仕事を残してほしい

僕は、AIへ質問することを、知識のある人だけの行為にしたくありません。

まだ言葉になっていない悩みがあってよい。どの資料が必要か分からない状態から始まってよい。最初の案が、うまくいかなくても構いません。

その代わり、対話を通して少しずつ具体的にしたいと思っています。

何を決めたいかが分かる。使える材料が分かる。複数の案を比べられる。選んだ理由を説明できる。そして、実際の文章、資料、仕事の手順、動く仕組みとして残る。

その変化を支えるために、ChatGPTやCodexを使いたいのです。

僕自身も、すべての答えを持つ人としてではなく、問いを立て、確かめ、作り直す人として発信を続けたいと思っています。

相談しただけで終わらない。答えを読んだだけで終わらない。自分で選び、次へ進める仕事をつくる。

Gt.Onを、そのための視点が集まる場所にしていきます。

株式会社S.Line 代表取締役

岡田 颯太

Gt.Onの記事一覧から、いまの相談や制作に近いテーマを一つ選んでみてください。取材・事業の相談は、株式会社S.Lineのお問い合わせ窓口をご確認ください。