Archive
AIの使い方
仕事でAIを使うときの頼み方と、確かめ方のポストですわ。
-
「開発用AIへの指示が長くなってきたら、毎回守る決まりと、特定の作業だけで使う手順を分ける方法があります。」を読む
開発用AIへの指示が長くなってきたら、毎回守る決まりと、特定の作業だけで使う手順を分ける方法があります。GitHub Copilotの公式ガイドでは、共通の指示とAgent Skillsを別の役割として説明しています。 たとえば「既存の変更を消さない」「テスト結果を報告する」は普段の開発でも守る指示。一方、月次レポートの作り方や独自のデータ移行手順は、その作業をするときに必要な情報です。後者を全部、常時読む指示へ詰め込むと、関係のない作業でも長い手順を抱えることになります。 分けるときは、まず直近の依頼を見て、どの作業でその手順を使うのか書き出します。スキルの説明には「何をする手順か」だけでなく「どんな依頼で使うか」を書くと、適用する場面を判断しやすくなります。 ファイルを作っただけで期待どおりに使われるとは限りません。同じ練習用の依頼で、必要な手順が参照されるか、無関係な作業で使われないかを確かめます。対応する保存場所や呼び出し方は製品で違うので、他のAIツールへ移すときも、その製品の仕様に合わせる必要があります。
-
「Power Automateで申請を処理するなら、成功時のメールと一緒に、失敗時の連絡先も決めておきたいです。」を読む
Power Automateで申請を処理するなら、成功時のメールと一緒に、失敗時の連絡先も決めておきたいです。途中の処理が止まったのに、担当者は「通知が来ないから申請がない」と受け取る可能性があります。 作り方の一例は、通常の処理をTryというスコープにまとめ、失敗を受け取るCatchを別のスコープにする形。Catchの「実行条件の構成」で失敗やタイムアウトを対象にすると、通常の処理が通らなかった場合の通知を分けられます。Microsoftの公式ガイドにもこの構成が載っています。 通知には申請番号、止まった処理、実行履歴を調べるための情報を入れます。申請者の全文や個人情報を、そのまま広いチャットへ流す必要はありません。後で担当者が対象を見つけられる情報を選びます。 練習用の申請で、保存先が使えない場合や必須項目がない場合を確認すると、正常系だけでは見えない設定を点検できます。Catchで通知しただけで成功扱いにしてよいかも要確認。処理が完了していない場合は、失敗状態を残す設計にしておくと、実行履歴と通知の意味がそろいます。
-
「AIエージェントに集計ファイルを保存させるなら、「ファイルがある」だけで完了にせず、受け取る側が使えるかまで確認したい。」を読む
AIエージェントに集計ファイルを保存させるなら、「ファイルがある」だけで完了にせず、受け取る側が使えるかまで確認したい。 たとえば20件の集計をJSONで保存する仕事。 0バイトではない、JSONとして開ける、20件ある、IDが重複していない、必要な項目がそろっている、までを完了条件にする。 中身が空の配列でも、保存自体は成功しているから。 依頼文は「保存後にそのファイルを読み直して、件数・必須項目・ID重複・元データとの合計を照合して。結果と保存先を報告して」。 AIが作った途中の値ではなく、実際に保存されたファイルを読むところがポイント。 記録は、入力ファイルの版/出力先/照合結果/確認時刻をひと組にする。 あとで上書きされた可能性がある仕事なら、ファイルのハッシュも残す。 同じ名前でも内容が変わったことを区別できる。 開けない、件数が足りない、合計が合わない場合は完了扱いにせず、原因を分けて調べる。 ファイルを確認できたことと、外部サービスへ登録できたことも別。 予約なら登録先のIDを取得して、日時や本文を読み直して照合する。

-
「AIに社内資料を渡すとき、関連しそうなファイルを全部入れていませんか。」を読む
AIに社内資料を渡すとき、関連しそうなファイルを全部入れていませんか。古い手順と新しい手順が混ざると、長く詳しい回答でも、どの決まりに従ったのか分からなくなります。 たとえば経費精算の案内を作るなら、現行の規程、今回の質問、適用される例外だけを先に渡す方法があります。過去の議事録や廃止済みの案内は別に置き、必要になった部分を追加します。資料の量を減らすこと自体が目的ではありません。答えの判断材料をそろえるためです。 頼み方は「現行規程を優先し、旧版と食い違う箇所は旧版を採用せず報告して。質問に関係のない章は要約しなくてよい」。ファイル名だけで新旧を推測させず、適用日と版を添えると比較する対象も明確になります。 返ってきた案内は、例外に当たる質問でも確かめます。必要な規程まで削ると、簡潔でも誤った回答になり得るからです。Anthropicのコンテキスト設計の解説も、関連する情報を選んで渡す考え方を扱っています。長い入力を作る前に、今の質問で判断に使う資料を選びたいですね。
-
「AIで文書の一部だけ直すとき、修正箇所の指定に加えて「採用する単位」を決めておくと、意図しない変更を混ぜにくい。」を読む
AIで文書の一部だけ直すとき、修正箇所の指定に加えて「採用する単位」を決めておくと、意図しない変更を混ぜにくい。 例として、2段落目だけ読みやすくしたい文書。 最初に段落へP1、P2、P3と番号を付け、「P2だけを提案して。数字・固有名詞・条件は変更しない。ほかの段落は返さなくていい」と頼む。 提案は、元の文/修正案/理由/事実の変更有無の表にする。 「短くなった」だけで採用せず、対象や例外が落ちていないかを見る。 数字を含む文なら、数値が同じでも『最大』や『予定』が消えていないかを確かめる。 採用した案だけを元の文書へ差し込み、前の版との差分を確認する。 P1とP3にも差分があれば保留。 全文を書き直してから探すより、変更範囲を先に狭めておくほうが照合しやすい。 受け渡しには、採用した段落IDと理由、元の版を添える。 案が複数出たときも、どれを反映したかが残る。 書式変更や改行の差分が多い文書では、本文の変更と表示だけの変更を分けて見ておきたい。

-
「AIで社内メモを報告書にするなら、文章を整える前に「どの行がどの事実を指すか」を残しておくと確認しやすい。」を読む
AIで社内メモを報告書にするなら、文章を整える前に「どの行がどの事実を指すか」を残しておくと確認しやすい。 たとえば入力が「A:参加は約120人」「B:来月公開の予定」「C:遅れの原因は人手不足かもしれない」。 Aは概数、Bは予定、Cは推測。 これを「120人が参加し、来月公開する。原因は人手不足だ」と整えると、読みやすくても内容は変わっている。 依頼は「各行にIDを付けたまま文章化して。数字・単位・対象・時期・確実さを保ち、根拠がない補足は別欄に出して」。 完成文とは別に、入力ID/採用した文/変更点の対応表も返してもらう。 確認するのは「約」の数だけではない。 Aの人数が誰の人数か、Bの予定日が確定日に変わっていないか、Cが結論扱いになっていないかを行ごとに照合する。 消えた行や、入力にない数字もこの表で見つける。 内容を直した後も対応表は残す。 文章だけを次の担当へ渡すと、何を根拠に直したかが分からなくなる。 社内メモを扱うなら、使えるAIの範囲も先に確認しておきたい。

-
「お客さんごとのメールをAIで何通も作るときは、1通ずつ書かせるより「ひな形」と「差し込み」に分けたほうがミスが少ない。」を読む
お客さんごとのメールをAIで何通も作るときは、1通ずつ書かせるより「ひな形」と「差し込み」に分けたほうがミスが少ない。 ひな形は〔会社名〕〔氏名〕〔納期〕のような空欄つきで作ってもらい、中身は顧客の一覧表から入れる。これなら、前の相手の名前が本文の途中に残りにくい。差し込み自体は、Wordの差し込み印刷でもスクリプトでもいい。 それでも起きやすいのが「山田様様」。一覧表の氏名欄にもともと「様」が入っていると、ひな形の「様」と重なる。担当者名が空欄の行で「株式会社○○ 様」になるのも気をつけたい。会社や部署あてなら「御中」なので、氏名が空の行は書き方を分ける。 日付も崩れやすい。Excelの日付を差し込むと、ただの数字や「10/1/2026」の並びで入ることがある。 送る前に見るのは、全件でなくていい。一覧の先頭の行、最後の行、それから空欄のある行。これを自分あてに送って、スマホでも開いてみる。 最後に、ほかの宛先の会社名で全件を検索して、1件も出てこないことを見る。添付ファイルの名前に別の会社名が入っていることもあるので、本文とは別にそこも見ておく。

-
「「未返信で、期限を過ぎた案件だけ出して」」を読む
「未返信で、期限を過ぎた案件だけ出して」 これをAIにExcelの式やコードにしてもらうなら、答え合わせ用の表を先に作っておくと話が早い。 未返信・期限切れ → 出る 未返信・期限内 → 出ない 返信済み・期限切れ → 出ない 返信済み・期限内 → 出ない 未返信・期限が空欄 → ? この5行を小さなシートに入れて式を当てれば、出てくるのが1行目だけかどうかで、すぐ正しさが分かる。 ExcelのFILTER関数だと、条件どうしを「*」でつなげば「かつ」、「+」なら「または」。 =FILTER(A2:D100,(C2:C100="未返信")*(D2:D100<TODAY())) 記号が1つ違うだけで、出てくる案件がまるで変わる。 見落としやすいのが5行目。空欄のセルは比べるときに0として扱われるので、この式だと期限を入れていない案件まで「期限切れ」で出てくる。期限のない案件をどう扱うかは、式の前に人が決めておきたい。 期限が「今日」の案件も同じで、含めるなら「<=」、含めないなら「<」。どちらが正しいかは式では決まらないので、依頼文に書いておく。

-
「どのAIの答えがいいか比べるなら、サービス名を隠してから読むのがおすすめ。」を読む
どのAIの答えがいいか比べるなら、サービス名を隠してから読むのがおすすめ。 同じ質問を3つのAIに聞いたら、回答をA・B・Cとだけ書いて並べ替える。ふだん使っているサービスの答えは、どうしても甘めに読んでしまうから。最初に読んだ答えが基準になりやすいので、並び順も質問ごとに入れ替える。 読む前にやっておきたいのが、「入っていてほしい項目」のメモ。これを先に書いておかないと、最初に読んだ答えの中身が、そのまま採点の基準になってしまう。 見るのは、事実の誤り、メモした項目の抜け、指示どおりの形で返ってきたか。長い回答は丁寧そうに見えるけど、長さは点数に入れない。 質問には、自分が正解を知っているものを混ぜるといい。前に自分で調べ終えた件や、手元に答えのある計算など。正解が分からないまま比べると、もっともらしい間違いに高い点をつけてしまう。 もうひとつ、1回ずつの比較だと当たり外れが大きい。同じ質問を2〜3回ずつ出して、毎回ぶれずに答えられたほうを選びたい。要約が得意なAIとコードが得意なAIが違うこともあるので、結果は用途ごとに、比べた日付と一緒に残しておく。

-
「画像の表をAIに読ませたときに見落としやすいのは、数字よりも記号と単位のほう。」を読む
画像の表をAIに読ませたときに見落としやすいのは、数字よりも記号と単位のほう。 決算資料の「△1,200」は、マイナス1,200という意味。▲や、英語の資料なら(1,200)のようなかっこ書きも同じくマイナスを表す。この記号が抜けると、減った金額が増えたように並んでしまう。表の上の「単位:千円」を読み落とせば、全部の金額が本当の1000分の1になる。 にじんだスキャン画像だと、「0」と「O」、「1」と「l」の取り違えも出やすい。セルを結合した表では、値が1行ずれて隣の項目に入ることもある。 頼むときは、こんなふうに書いておく。 「この画像の表を読み取って。見えたままの表記(記号と単位も含む)と、円にそろえた数値を別の列に。読めない文字は■のままにして、推測で埋めないで。最後に、明細を足した結果が合計の行と合うか計算して」 合計の行がある表なら、1か所の読み違いはたいていこの計算でずれて見つかる。ずれたときは、明細と合計行のどちらを読み違えたのか、画像を拡大して両方見直す。合計の行がない表は検算できないので、せめて行と列の数が元の表と同じかだけは数えておきたい。

-
「AIに予約日時を渡すなら、「9月30日0時30分」だけでは足りない。」を読む
AIに予約日時を渡すなら、「9月30日0時30分」だけでは足りない。 日本時間の9月30日0時30分は、UTCでは9月29日15時30分。同じ瞬間でも日付が変わるので、保存結果の「29日」を見て即ミスと決めつけるのも危ない。 依頼は「2026-09-30 00:30、Asia/Tokyo」。確認は保存された時刻を日本時間へ戻して照合する。文字列が同じかではなく、同じ瞬間を指しているかを見るのがコツ。
-
「顧客一覧と注文一覧をAIで結合するなら、最初に「1行は何を表すか」を決める。」を読む
顧客一覧と注文一覧をAIで結合するなら、最初に「1行は何を表すか」を決める。 顧客はAさん・Bさんの2人。注文はAさんが3件、Bさんが1件。注文ごとに結合した4行を数えても、顧客が4人になったわけじゃない。 「売上は注文ID単位、顧客数は重複しない顧客IDで数える」と指定して、結合前後の人数を確認する。表が増えたのか、人が増えたのか。そこを分けるだけで、もっともらしい誤集計を見つけやすい。
-
「AIに長い依頼を一気に渡すより、最初に「完成条件」を3行で固定すると迷子が減る。」を読む
AIに長い依頼を一気に渡すより、最初に「完成条件」を3行で固定すると迷子が減る。 ①何を作るか ②変えてはいけないもの ③合格の確認方法。 手順はAIに考えさせても、ゴールだけは人が先に決める。ここが曖昧だと、丁寧な遠回りが始まる。
-
「AIにアンケートを集計させるとき、空欄を0で埋めるのは一旦ストップ。」を読む
AIにアンケートを集計させるとき、空欄を0で埋めるのは一旦ストップ。 購入回数が「0回・2回・未回答」の3人なら、回答者の平均は1回。未回答を0回にすると約0.67回になる。見た目は整っても、別の集計だ。 依頼には「未回答は欠損として残す。平均には回答者数を添える」と一文追加。空欄をなくすことと、情報を正確にすることは同じではない。
-
「Imagine Image 2の使い方記事では、リサイズは仕上げのあと、と繰り返し出てきます。」を読む
Imagine Image 2の使い方記事では、リサイズは仕上げのあと、と繰り返し出てきます。新しいモデル発表ではなく、編集とSmart Resizeの並びの話です。 先にメインの一枚を確定させてから比率を変える。変えたあとは文字を毎回見る。編集は一つずつ。ラベルと背景と光を一度に頼むと中途半端になる、と書かれています。わたくしなら、手元の縦スクショ一枚で切り抜きとリサイズだけ試します。既存のスライドに載せる前に、1枚で向き不向きを見たいですわ。 https://grok.com/imagine
-
「Deep ResearchをAPIで回すときは、結果だけでなく調査経路も確認したいですの。」を読む
Deep ResearchをAPIで回すときは、結果だけでなく調査経路も確認したいですの。 Gemini Deep Researchはバックグラウンド実行が前提で、Google Search、URL Context、Code Executionを使い、File SearchやリモートMCPも接続できます。わたくしなら、許可する情報源を狭めた小さな調査から始め、引用先と計算を人が再確認します。 公式ガイド https://ai.google.dev/gemini-api/docs/deep-research
-
「エージェントの中間結果を全部モデルへ戻すと、判断より整理にトークンを使いがちですの。」を読む
エージェントの中間結果を全部モデルへ戻すと、判断より整理にトークンを使いがちですの。 OpenAIのGPT-5.6実装ガイドは、検索の絞り込みや集計をProgrammatic Tool Callingのコード側へ移し、モデルは判断に集中させる構成を紹介しています。まず同じ評価を通常版とコード処理版で走らせ、品質と入力トークンを比べると効果を確かめやすいですわね。 公式ガイド https://openai.com/index/builders-guide-to-gpt-5-6/
動画つき。Xの元ポストで再生できますわ。
-
「長いエージェント処理で、毎回履歴を全部送り直すのは少し重いですの。」を読む
長いエージェント処理で、毎回履歴を全部送り直すのは少し重いですの。 Gemini Interactions APIはprevious_interaction_idで前回の状態を引き継ぎ、バックグラウンド実行にも対応しています。わたくしなら、同じタスクを状態保存ありとstore=falseで一度ずつ動かし、再現性とトークン量を比べます。 公式ガイド https://ai.google.dev/gemini-api/docs/interactions-overview
-
「AIエージェントの自動化は、実行前に止められる場所があると扱いやすくなりそうです。」を読む
AIエージェントの自動化は、実行前に止められる場所があると扱いやすくなりそうです。 わたくしなら、まず小さく試してみます。 Claude CodeのHooksは、ツール実行や終了などのイベントでスクリプト等を動かせます。危険な操作の遮断、ログ記録、完了通知など、1つの目的から小さく始めるのがよさそうです。
-
「大きめのPDFや動画を何度も送るなら、毎回インライン添付しない方法もありますの。」を読む
大きめのPDFや動画を何度も送るなら、毎回インライン添付しない方法もありますの。 GeminiのFiles APIは、ファイルを先にアップロードして複数リクエストから参照する仕組み。保存期間や対応形式があるため、恒久保管ではなく一時的な分析素材として考えるのがよさそうです。
-
「AIのJSONを毎回パース修正しているなら、Structured Outputsを先に試してもよさそうです。」を読む
AIのJSONを毎回パース修正しているなら、Structured Outputsを先に試してもよさそうです。 こういう実務寄りの話、わたくしは好きですわ。 Gemini APIではJSON Schemaで返却形式を指定できます。自由文をあとから整えるより、必要な項目・型・必須条件を先に決める方が、後工程を軽くできるかもしれません。 対応するSchemaや注意点はこちらです。 https://ai.google.dev/gemini-api/docs/structured-output
-
「計算を文章だけで考えさせるより、コード実行を使った方が確かめやすい場面もありそうです。」を読む
計算を文章だけで考えさせるより、コード実行を使った方が確かめやすい場面もありそうです。 便利そうですが、条件は見ておきたいですわね。 Gemini APIには、モデルがPythonコードを作って実行し、その結果を回答へ反映する機能があります。表計算や簡単な分析で使うなら、入力データと出力を別でも検算しておくと安心です。 利用方法と制約は公式ガイドにあります。 https://ai.google.dev/gemini-api/docs/code-execution
-
「WebページをGeminiへ読ませるなら、検索結果ではなく直リンクを渡す方法もあります。」を読む
WebページをGeminiへ読ませるなら、検索結果ではなく直リンクを渡す方法もあります。 わたくしなら、まず小さく試してみます。 URL contextは1回に最大20URLを扱い、HTMLやPDFなどを取得できます。ただしログイン必須ページやlocalhostは対象外。取得量も入力トークンへ入るので、必要なページだけ選ぶのがよさそうです。 対応形式や制限はこちらです。 https://ai.google.dev/gemini-api/docs/url-context
-
「数分かかるAI処理をHTTP接続の長さで支えるのは、少し心配ですわね。」を読む
数分かかるAI処理をHTTP接続の長さで支えるのは、少し心配ですわね。 OpenAIのbackground modeは、処理を非同期で始め、responseの状態を後から確認する仕組み。深い調査や長めの生成でタイムアウトが気になるとき、候補になりそうです。 状態確認や制約は公式ガイドで確認できます。 https://developers.openai.com/api/docs/guides/background
-
「AIエージェントは、モデルを替える前に「履歴の渡し方」を疑った方がいい。」を読む
AIエージェントは、モデルを替える前に「履歴の渡し方」を疑った方がいい。 OpenAIは同じGPT-5.6 Solで、推論保持とcontext compactionを有効化するとARC-AGI-3が13.3%→38.3%、出力トークンは約1/6になったと報告。 器で性能が変わる例です。 公式 参照した公式情報・詳細はこちらです。 https://openai.com/index/how-two-settings-tripled-our-arc-agi-3-scores
-
「本日投稿したAI・開発情報のうち、予約文字数の都合で末尾リンクが表示されなかった4件を補足します。」を読む
本日投稿したAI・開発情報のうち、予約文字数の都合で末尾リンクが表示されなかった4件を補足します。 URLと確認ポイントを、以下にまとめます。 ① OpenAI Batch API 急ぎでない分類・評価などをまとめて処理する選択肢です。対象エンドポイント、24時間以内という処理枠、料金条件は公式ガイドで確認できます。 https://developers.openai.com/api/docs/guides/batch ② CodexとMCP 外部ツールをつなぐ際は、認証方法だけでなく、読み取りと書き込みの承認範囲も先に分けておくと扱いやすそうです。 https://learn.chatgpt.com/docs/extend/mcp?surface=cli ③ Codex Skills 繰り返す手順はSKILL.mdへまとめられます。説明文を入口にして、必要なときだけ詳しい手順や資料を読む構成がポイントです。 https://learn.chatgpt.com/docs/build-skills ④ Grok Build 公開されたのはモデル本体ではなく、文脈づくり・ツール実行・差分表示などを担うエージェント基盤です。コードと対象範囲はこちらで確認できます。 https://x.ai/news/grok-build-open-source
-
「Function callingは、AIが勝手に処理を終える機能ではない点が大事そうです。」を読む
Function callingは、AIが勝手に処理を終える機能ではない点が大事そうです。 Gemini公式の流れは、関数を定義→モデルが名前と引数を返す→アプリ側で実行→結果をモデルへ戻す、の4段階。決済や送信の直前に人の確認を入れたい設計とも相性がよさそうです。
-
「Gemini APIでも、同じ長い資料を繰り返し送る処理はキャッシュを確認しておきたいところです。」を読む
Gemini APIでも、同じ長い資料を繰り返し送る処理はキャッシュを確認しておきたいところです。 公式ではGemini 2.5以降の暗黙キャッシュが既定で有効。共通部分をプロンプトの前に置き、usageのcached tokensを見ると、実際に再利用されたか確かめられます。
-
「AIツールの新機能を見つけたとき、紹介文だけを読んで「使えそう」と決めないようにしています。」を読む
AIツールの新機能を見つけたとき、紹介文だけを読んで「使えそう」と決めないようにしています。 見るのは主に3つです。 1つ目は、同じ入力を何度か試して、結果の揺れ方を確認すること。1回だけうまくいった例より、失敗したときに何が起きるかの方が、実際の仕事では大切かもしれません。 2つ目は、出典やログを人が追えること。答えが自然でも、根拠へ戻れない仕組みは確認に時間がかかります。 3つ目は、止め方が分かること。外部ツールやデータ更新を伴うなら、実行前の確認、権限の範囲、取り消し方法まで見ておきたいところです。 新しいモデルの点数や速度は分かりやすい指標です。ただ、毎日使う道具として考えるなら、「間違えないか」だけでなく「間違えたときに気づけるか」も比べると、自分に合う選択肢が見えやすくなりそうです。
-
「プロンプトキャッシュが効かないときは、文章量より並び順を見直すとよさそうです。」を読む
プロンプトキャッシュが効かないときは、文章量より並び順を見直すとよさそうです。 続きはスレッドへ↓
-
「今すぐ返事が要らないAI処理は、Batch APIに回すと合うかもしれません。」を読む
今すぐ返事が要らないAI処理は、Batch APIに回すと合うかもしれません。 OpenAI公式では、同期APIより50%低いコスト、別枠のレート制限、24時間以内の完了を案内しています。夜間の分類や評価、埋め込み作成などから試しやすそうです。 対象エンドポイントも確認できます
-
「チケットやDBの結果を毎回チャットへ貼っているなら、MCPでつなぐ選択肢もあります。」を読む
チケットやDBの結果を毎回チャットへ貼っているなら、MCPでつなぐ選択肢もあります。 Codex公式ではOAuthや環境変数のBearer認証に加え、読み取りと書き込みで承認方法を分けられます。まずは使うツールだけ許可し、書き込み時に確認を残す形が安心かもしれません。 設定項目はこちら
-
「同じ長いプロンプトを二度書いたら、スキル化を考えてもよさそうです。」を読む
同じ長いプロンプトを二度書いたら、スキル化を考えてもよさそうです。 CodexのスキルはSKILL.mdを中心に、必要ならスクリプトや参考資料もまとめられます。最初は名前と説明だけが見え、必要なときに本文を読む設計なので、毎回すべてを詰め込まずに済みます。 作り方はこちら
-
「Codexへ口調やテスト手順を毎回説明しているなら、AGENTS.mdが合いそうです。」を読む
Codexへ口調やテスト手順を毎回説明しているなら、AGENTS.mdが合いそうです。 公式では、プロジェクトの上位から作業フォルダへ向かって指示を読み、近い階層の内容を後から重ねます。共通ルールと機能別ルールを分けたいときに使いやすそうです。 仕組みはこちら https://learn.chatgpt.com/docs/agent-configuration/agents-md
-
「AIへの指示は、長いほど良いとは限らないようです。」を読む
AIへの指示は、長いほど良いとは限らないようです。 OpenAIはGPT-5.6向けに、重複した指示を減らし、必要なツールだけ見せる方法を案内しています。まず効いている指示を1群ずつ外し、同じ評価で比べてみるのが現実的かもしれません。 試す前の確認はこちら https://developers.openai.com/api/docs/guides/latest-model
速報はXに先に出しますの
このサイトは、Xのポストを詳しく読むための場所ですわ。いちばん早いのはXですので、よろしければフォローしてくださいまし。