大規模言語モデル(LLM)は、同じ内容のプロンプトでも「書き方」や「情報の並べ方」によって答えが変わることがあります。Google Researchの研究者らは、プロンプトをそのまま2回並べるだけの単純な手法により、LLMが多くの問題で正答しやすくなると報告しました。
この手法は「Prompt Repetition(プロンプト反復)」と呼ばれ、入力を「＜指示文＞」から「＜指示文＞＜指示文＞」に変換するだけです。つまり、指示や問題文をコピーしてそのまま2回連続で貼り付ければOK。「同じことを2回言えば通じやすい」という発想にも思えますが、研究チームの狙いは説得ではなく、LLMの読み取り方に由来する取りこぼしを減らすことです。
研究チームはプロンプト反復の派生系も試しており、プロンプトを3回繰り返す「×3」や、「Let me repeat that:」のように繰り返しを明示する形でも検証したところ、タスクによっては「×3」でさらに良い結果になる場合があることが示されました。
さらに、研究チームは単に入力を長くしただけでは正答率が改善しないことを確かめるために同じ長さになるように「.」で埋めるPaddingも試しましたが、成績は上がらなかったとのこと。
研究チームは、長ければ良いのではなく「同じ内容をもう一度読ませる」こと自体が効いている可能性があるとまとめています。
⇧ 何と言うか、
- タスク
- 繰り返し回数
の適切な「組み合わせ」を探すのが大変そうですな...
「組み合わせ」というと、「組合せ爆発」という「離散最適化問題」の問題が人口に膾炙しているのですが、
組合せ爆発（くみあわせばくはつ、英: combinatorial explosion）は、計算機科学、応用数学、情報工学、人工知能などの分野では、解が組合せ（combination）的な条件で定義される離散最適化問題で、問題の大きさn に対して解の数が指数関数や階乗などのオーダーで急激に大きくなってしまうために、有限時間で解あるいは最適解を発見することが困難になることをいう。
それでもね。私はみんなに「組み合わせ爆発のすごさ」を教えたいの！ 止めないで！
日本科学未来館で展示されている「フカシギの数え方」。そこで上映されているアニメが壮絶すぎると話題になっています。動画はYouTubeでも公開中。
⇧ 上記の「フカシギの数え方」の動画を思い出してしまいますな...
「AI」の利用については、「ゲーム」の「攻略本」みたいな「情報」が必要になって来そうですな...
VS Codeで『The extention 'GitHub' wants to sign in using GitHub.』の確認ダイアログが邪魔過ぎるが...
「VS Code（Visual Studio Code）」で「Git」操作の内、「認証」が必要な操作を実施する際に、
⇧ 上記のような「ダイアログ」が表示されて、邪魔過ぎると思ったことありませんか？
で、公式の「ドキュメント」だと、
Signing in with a personal access token (PAT) is only supported with GitHub Enterprise Server. If you're using GitHub Enterprise Server and want to use a PAT, you can select Cancel on the sign in prompts until you are prompted for a PAT.
⇧「Cancel」を選択後、「認証情報」を入力してくださいと...
流石に、面倒過ぎるのだが...
そもそも、「業務」で貸与されている「開発用端末」から「Web画面」で「GitHub」の「SignIn」が許可されていないので、毎回、「Cancel」を選択することになって地獄ですと...
で、
⇧「issue」も上がっているぐらいなので、海外勢も誠に遺憾であると思っているようですと。
『The extention 'GitHub' wants to sign in using GitHub.』の確認ダイアログが表示されるのは「VS Code（Visual Studio Code）」の仕組み起因らしい...
「issue」だと「VS Code（Visual Studio Code）」の「拡張機能」が影響しているとのことなのだが、「VS Code（Visual Studio Code）」の公式の「ドキュメント」を見る限り、「VS Code（Visual Studio Code）」の「デフォルト」の状態で『The extention 'GitHub' wants to sign in using GitHub.』の確認ダイアログが表示されるようになってしまっている気がするのよね...
で、
⇧「stackoverflow」によると、「settings.json」に設定を追加すれば『The extention 'GitHub' wants to sign in using GitHub.』の確認ダイアログを表示できなくすることができるらしいですと。
「Google Gemini」に質問してみたところ、以下のような回答が返ってきた。
そのメッセージが出るのであれば、犯人は Git Graph ではなく、VS Code に内蔵されている 「GitHub 認証プロバイダー」 です。
VS Code は、PAT（トークン）を自分で管理するよりも、公式の認証機能を使ってブラウザログインさせる方を優先しようとします。その「お節介」を
settings.jsonで完全に封じ込める設定は以下の通りです。
■settings.json に追加する最終構成
{
// 1. VS Code本体のGitHubログイン機能を無効化（これが最重要）
"github.authentication": false,
// 2. ターミナルでのGit操作にVS Codeが介入するのを防ぐ
"git.terminalAuthentication": false,
// 3. GitHubへのサインイン提案（ポップアップ）を無効化
"github.signin.preferred": false
}
これで何が起きるか
- ダイアログが出なくなる: VS Code が GitHub にサインインしようとしなくなるため、あのメッセージは表示されなくなります。
- Git認証が「Git本来の動き」に戻る: VS Code を介さず、Git 自体が認証を探しに行くようになります。
次にあなたがやるべきこと
上記の設定を保存した後、Git は「どこに PAT があるかわからない」状態になります。そこで、OS の機能を使って PAT を保存させます。
1. Linux VM側：認証情報の保存設定（Global）
Linuxのターミナルで以下のコマンドを実行します。これにより、あなた専用の ~/.gitconfig に設定が書き込まれ、他メンバーには影響しません。
# 認証情報をディスクに暗号化せず保存する場合（自分専用VM向け） git config --global credential.helper store # または、メモリに一定時間だけ保存する場合（より安全） # 3600秒（1時間）キャッシュします git config --global credential.helper 'cache --timeout=3600'
2. VS Code側：リモート設定 (settings.json)
VS Codeがブラウザ認証を優先してエラーになるのを防ぐため、リモート側の settings.json を設定します。
VS CodeでVM接続中に Ctrl + , ＞ 「リモート」タブを選択。
以下の設定を true にします（これにより、VS CodeがGitの資格情報マネージャーを適切に扱えるようになります）。
{
"git.terminalAuthentication": true,
"github.authentication": true
}
3. 最初の1回だけ手動でプッシュ
📌 最初の1回だけ必要なこと
✅ CLIで対応する場合
- VS Code 内のターミナルで
git pushと打ちます。 - ターミナル内で
Usernameを聞かれるので入力します。 Passwordを聞かれたら PAT を貼り付けて Enter を押します。
✅ GUIで対応する場合
GUIで「プッシュ」を押した際、もし settings.json で設定済みであれば、VS Codeの上部中央（コマンドパレットのような位置）に小さな入力欄が表示されます。
これだけで、OS（Windows/Mac）がその情報を記憶します。2回目以降のGUI操作では、何も聞かれずにボタン一つでプッシュが完了するようになります。
これだけで、次回からは 「ダイアログも出ない」「ブラウザも開かない」「PATの再入力も不要」 という、あなたが求めていた理想の環境になります。
もしこれでも「Sign in using GitHub」が出る場合は、VS Code の左端にある 「アカウント（人の形のアイコン）」 をクリックし、サインインしている GitHub アカウントがあれば一度 「サインアウト」 を選択してみてください。
ちなみに、
⇧ 上記サイト様によりますと、「公開鍵」による「認証」もありますと。
ただ、「業務」で「開発」してる場合については、「GitHub」の「Organization」などの「Gitリポジトリ」を利用する関係上、「SSO（Single Sign On）」などの設定が要りそうなのだが、
⇧ 公式の「ドキュメント」によりますと、「PAT（Personal Access Token）」だけでなく、「公開鍵認証」についても、「SSO（Single Sign On）」に対応していそうではある。
「Google Gemini」に『複数人で開発場所が同じ場合でも、Git操作で認証が必要な操作について公開鍵認証を導入して、他メンバーに影響ない？』と質問してみたところ、以下のような回答が返ってきた。
結論から申し上げますと、「他メンバーに影響を与えず、あなただけ公開鍵認証（SSH）を使うこと」は完全に可能です。
GitのリモートURL設定（git remote set-url ...）は、リポジトリ内の .git/config ファイルに保存されますが、このファイルは通常 .gitignore の対象外（※）であり、サーバー（GitHub等）にはプッシュされません。
※ 通常 .gitignoreに書かれていないファイルは Git の管理対象（ステージング可能）になりますが、.gitディレクトリ（その中の config ファイル含む）だけは、Git の仕組み上、絶対にプッシュできないという特殊なルールがあります。
つまり、あなたの手元のLinux VM内にある .git/config を書き換えても、他のメンバーの環境や共有されているコードには一切影響しません。
なぜ .git/config はプッシュされないのか？
Git リポジトリの構造を見ると分かりやすくなります。
実は、Git において「プッシュされるもの」は、ワークツリーにあるファイル（Gitが追跡しているもの）だけです。
.git/ ディレクトリ自体は、そのリポジトリの「心臓部」であり、個人の設定（URL、フック、履歴データなど）が詰まっています。このディレクトリの中身は、Git コマンドによって同期されることはあっても、ファイルとしてプッシュされることは物理的にありません。
[!IMPORTANT] 結論 あなたが git remote set-url で SSH に書き換えた設定（.git/config）は、あなたの PC（または VM）の中にだけ存在し続けます。 他の人が git pull をしても、あなたの個人設定が彼らの PC に届くことは 100% ありません。
✅ なぜ影響しないのか？
Gitの設定には「3つのレベル」があり、今回変更するのは一番下の Local です。
他のメンバーが git pull をしても、あなたのローカルにある .git/config（SSH設定）が彼らに上書きされることはありません。
彼らは引き続き HTTPS で作業できます。
なるへそ。
追加で『WindowsのVS Code からリモートSSHでLinux VMに接続して作業する前提で、公開鍵認証でGit操作するための設定の完全な手順をお願いします。』と質問してみたところ、以下のような回答が返ってきた。
すでに鍵がある場合は、新しく作る必要はありません。
1. PowerShellを管理者として開き、SSHエージェントを有効にします。
# サービスの開始 Set-Service -Name ssh-agent -StartupType Automatic Start-Service ssh-agent
2. 鍵を作成します（すでにある場合は不要です。すべてEnter連打でOK）。
# 鍵をエージェントに登録 (id_ed25519 の部分は自分の鍵の名前に合わせてください) ssh-add $env:USERPROFILE\.ssh\id_ed25519
3. 公開鍵をコピーします。
cat $env:USERPROFILE\.ssh\id_ed25519.pub | clip
4. GitHubのSSH設定を開き、「New SSH Key」から貼り付けて保存します。
✅ ステップ2：VS Codeの「転送（Forwarding）」設定
Windowsにある鍵をLinux VMでも使えるようにします。
Windows側のVS Codeで C:\Users\ユーザー名\.ssh\config を開きます。 接続先のホスト設定に ForwardAgent yes を追記します。
# 1. 共通認証ポリシー（開発用）：すべてのSSH接続でWindowsの鍵転送を許可する Host * ForwardAgent yes ServerAliveInterval 60 # 2. 個別ログイン設定：各VMへの接続情報を定義する Host <VMの識別名（例：my-vm）> HostName <VMのIPアドレス> User <Linuxのユーザー名> Port <ポート番号> # ← ここにポート番号（例: 22 や 10022 など）を記述 PreferredAuthentications password
✅ ステップ3：VS Codeの干渉を無効化する（詳細手順）
Ctrl + , (コンマ) で設定画面を開きます。 設定画面の上部にあるタブから、「リモート [SSH: <VM名>]」 を選択します。
※「ユーザー」タブでも効きますが、「リモート」タブに書くことで、そのVMで作業する時専用の設定として明示できます（単一責任の考え方に近い運用です）。
右上の「設定(JSON)を開く」アイコンをクリックします。 以下の設定を追記します。
{
"github.authentication": false,
"git.terminalAuthentication": false,
"git.confirmPush": false
}
✅ ステップ4：Linux VM側：Git の共通変換設定（あなた専用）
リポジトリを跨いで自動化するために一度だけ実行します。
git config --global url."git@github.com:".insteadOf "https://github.com/"
結論から申し上げますと、git config --global を設定しても、他のメンバーには一切影響しません。
理由は、--global 設定が保存される場所にあります。
1. 設定の保存場所の違い
Gitの設定ファイルは、以下の場所に保存されます。
--local: リポジトリ内の.git/config- そのリポジトリ専用の設定。
--global: あなたのホームディレクトリの~/.gitconfig- あなたのユーザーアカウント専用の設定。
他のメンバーが同じ Linux VM を使っていたとしても、各ユーザーのホームディレクトリ（/home/ユーザー名/）は分かれています。
そのため、あなたが自分のホームディレクトリの設定を書き換えても、他のユーザーの Git の挙動が変わることはありません。
ましてや、GitHub を通じて他のメンバーの PC にこの設定が届くことも、構造上 100% あり得ませんのでご安心ください。
📌 この構成のメリット（まとめ）
- VMログイン: 役割通り「パスワード認証」で行う。
- Git操作: あなたのホームディレクトリ内の設定（Global）によって、裏側で Windows の鍵を使った SSH 通信に自動変換される。
- 他メンバーへの影響: あなた個人の設定ファイル（
~/.gitconfig）をいじっているだけなので、完全にゼロです。
これで、複数のリポジトリを扱っても、常に「GUI のボタン一発でプッシュ」ができる理想の環境になります。
この insteadOf の設定を Linux 側で試してみてください。
まぁ、「VS Code（Visual Studio Code）」の設定って本当に分かり辛いですよね...
何と言うか、個別で設定が必要になって来る部分は、チーム内で「ドキュメント」化しておきたいですな...
兎にも角にも、「開発環境構築」は整備したいところですな...
本質的な「開発」とは関係ない部分の煩わしさを何とかしたいのですけどね...
所謂、『俺の環境だと動くけど、何か？』みたいな状況を無くしたいのよね...
ちなみに、
⇧ 上記サイト様で「Vagrant」が紹介されていますが、「Vagrant」も『俺の環境だと動くけど、何か？』の問題を完全に解決してくれるわけでは無いのよね...
まぁ、そもそも、「VS Code（Visual Studio Code）」以外で「開発」してるケースもあるので、何とも言えませんが...
俗に言う「オレオレ環境」が横行しますな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
