ArcGIS Enterprise 12.1 (windows) proxy bug 忘備録

Proxy を使用していると、何かと動作しない事が多く、その対処法。

まず、ArcGIS の C# SDKだが、Windows の proxy の設定を見て動作する。
インターネット・オプションの proxy から除外するリストも設定しないと、
https://foo.local-ad.bar.co.jp:6443 へのアクセスに　proxy を介しようとしてはまる。
設定すべきは、

https://[arcgis-server-machine];https://localhost

netsh winhttp set proxy の情報を見ているのか、実行ユーザのインターネット・オプションの情報を見ているのかは定かではない(調べてません)
さて、Linux系のツールでは、環境変数

http_proxy
https_proxy
no_proxy

の3種類を参照するものが主流だ。C# SDK もこれに対応しているのだが、詰めが甘い。
なんと no_proxy を見ないで、http_proxy, https_proxy が設定されている場合は、インターネット・オプションの proxy の設定を上書きし、proxyから除外するリストをクリアする。
no_proxy を設定していても見ないで無条件にクリアするので、Windows の環境変数に https_proxy=http://foo:8080 などと設定しようものなら、6443ポート宛てのアクセスをproxyを介しようとして WebAdaptorが動作しなくなる

さて、ここまでは序の口
色々動かしていると、動かないものが出てくる。今回は PrintingTool のサービスだった。こいつ、ArcGIS Server に設定した proxy 情報を見ないし、Portal for ArcGIS に設定した proxy 情報を見ないし、netsh winhttp set proxy で設定した proxy 情報も見ない。https_proxy 等の環境変数は、前述した問題があるので使用できない。
では、何を設定すれば proxy の情報を見てくれるのか？
arcgis server をサービスとして実行している arcgis というサービス用のウィンドウズ・アカウントのインターネット・オプションの情報に縛られる
PsExecを使って、サービス用アカウントのインターネット・オプションを設定すれば動作する

C:\> psexec64 -u "[localMachineName]\[arcgis]" -p password cmd.exe

別ウィンドウが立ち上がるのでインターネット・オプションを開いて Proxy の設定を行う。

C:\Windows\system32> inetcpl.cpl
C:\WIndows\system32> exit

これで、ちゃんと proxy を見てくれる。

git と diff

業務で使用していたバージョン管理システム、単発のプロジェクトならば Subversion で十分なんだが、ベースシステムの管理には向いていなくて、「大がかりな機能追加がしたい」とか、派生が多くなると Gitの方が使いやすそうなので git も使うようになりました。 branch を切って、branch をサブブランチに切り替えて作業をしている間にも、メインブランチにバグ修正が入ったりするとメインブランチで修正とコミットをして、サブブランチに取り込みたい。
サブブランチにて

git fetch
git merge origin/master

とやる機会が増えて来ました。

使っていて、merge で CONFLICT した状況を見ると、git 付属の diff が WinMerge の diff と比べて差分の認識が悪く merge 作業が大変です。
Gemini さんに相談したところ、diff も変更できるらしいです。
git ほんと、よくできたツールだ。

以下の質問をGeminiさんに投げてみました。

git 付属の diff と比較して、WinMerge 付属のdiff の方が賢い気がしています。
同じ diff ではないのでしょうか？

結論から言うと、Git付属の git diff と WinMerge は全く異なる「差分比較エンジン（アルゴリズム）」を使用しています。 そのため、比較の「賢さ」や結果の見た目に違いが生まれます。

WinMergeのほうが賢く感じるのには、明確な技術的理由があります。

1. 内部の比較アルゴリズムが違う

行単位で大雑把に比較するか、文字単位で細かく比較するかの違いがあります。

• git diff（デフォルト）：
• 主に「マイヤーズ（Myers）のアルゴリズム」[1] をベースにしています。
  • 行単位での変更（どの行が消えて、どの行が増えたか）を高速に探すのが得意です。
• WinMerge：
• 独自の高度な差分エンジン（改良されたアルゴリズム）を持っています。
  • 行単位の比較だけでなく、同じ行の中の「どの文字（単語）が変わったか」まで自動で細かく解析します。

2. WinMergeが「賢い」と感じる3つの理由

① 行内の部分一致（ハイライト）が強力

Gitは行単位で「この行が削除され、この行が追加された」と雑に判定しがちです。 WinMergeは「この行の、この変数名だけが書き換わった」のように、変更されたピンポイントの場所を明るい色でハイライトしてくれるため、脳の負担が減ります。

② 空白や改行コードの柔軟な無視

WinMergeは「スペースの数の違い」「タブとスペースの違い」「改行コード（CRLF / LF）の違い」を自動で無視する設定（または検知して警告する機能）が非常に強力です。Gitでこれらを行うには --ignore-space-change などのオプションを自分で指定する必要があります。

③ 移動した行（ブロック）の検知

コードの塊が「上の位置から下の位置へ移動しただけ」という場合、Gitは「ごっそり削除されて、別のごっそり追加された」と認識しやすいです。WinMergeは「これは移動しただけ」と見抜いて線で結んでくれる機能（移動ブロックの検出）があるため、より人間にとって直感的です。

ヒント：Git の比較画面を WinMerge に変更できます

もし WinMerge の見やすさで Git の差分を確認したい場合は、Git の外部差分ツール（difftool）として WinMerge を登録するのがおすすめです。 以下のコマンドをターミナルで実行すると設定できます：

git config --global diff.tool winmerge
git config --global difftool.winmerge.cmd '"C:/Program Files/WinMerge/WinMergeU.exe" -e -u -dl "Base" -dr "Mine" "$LOCAL" "$REMOTE"'

※WinMergeのインストールパスは環境に合わせて変更してください。 設定後は、いつものコマンドを少し変えるだけで WinMerge が起動します：

git difftool <対象ファイル>

もしよろしければ、以下を教えていただけますか：

• お使いのPCは Windows ですか？（MacやLinuxでも一部WinMergeの派生ツールが使えます）
• Gitのターミナル上（黒い画面）でWinMergeのように見やすく表示したいですか？、それともWinMergeのアプリを直接起動したいですか？

ご希望に合わせて、Gitの表示をより賢く・見やすくカスタマイズする手順をご案内します。

WIX で VCRuntime のインストール忘備録２

前回の記事は WIX で VCRuntime のインストール忘備録
アプリケーションを実行していると、以下の行で例外が発生(Access Violation)する環境がある

        std::lock_guard<std::mutex> lock(connection_string_mutex_);

デバッグのログを色々と埋め込んで状況を絞り込んで検証していったところ
AIにより

という状況に辿りついた。
インストーラでRuntimeのチェックをしていたが、どんどん新しいRuntimeが出て、
それでも動作するので、Runtimeのバージョンチェックをするのは得策でないという結論になり、
インストーラでのチェックを諦めたのだが、これは何とかしたい

そこで、古いバージョンで動かないRuntimeがインストールされている時だけエラーにする処理を模索した

        <!-- x86 版 -->
        <!-- Minor バージョン番号を整数で取得 -->
        <Property Id="VC_REDIST_MINOR_X86" Secure="yes">
          <RegistrySearch Id="VCRedistMinorX86"
            Root="HKLM"
            Key="SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\x86"
            Name="Minor"
            Type="raw"
            Win64="no" />
        </Property>

        <Condition Message="Visual C++ 2022 Redistributable (x86) 14.37 以降が必要です。&#10;vc_redist.x86.exe をインストールしてください。">
          NOT (VC_REDIST_MINOR_X86 AND VC_REDIST_MINOR_X86 &lt; "#37")
        </Condition>


        <!-- x64 版 -->
        <!-- Minor バージョン番号を整数で取得 -->
        <Property Id="VC_REDIST_MINOR_X64" Secure="yes">
          <RegistrySearch Id="VCRedistMinorX64"
            Root="HKLM"
            Key="SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\x64"
            Name="Minor"
            Type="raw" />
        </Property>

        <!-- Minor が存在して 37 未満の場合のみエラー -->
        <Condition Message="Visual C++ 2022 Redistributable (x64) 14.37 以降が必要です。&#10;vc_redist.x64.exe をインストールしてください。">
          NOT (VC_REDIST_MINOR_X64 AND VC_REDIST_MINOR_X64 &lt; "#37")
        </Condition>

いやはや、AIの進化は凄まじい。AIの助けなしだと１週間は時間を取られていたかもしれない。

Github copilot にお願いしたいこと

Github copilot にお願いしたい事がある。

モデルを１つ追加してほしい。経緯は以下

Question:

今応対していただいている Copilot - chat ですが、Github copilot のモデルだと、どれに相当しますか？　Microsoft Visual Studio の仕様に詳しいので、できれば、同じモデルにお願いしたいんです

Copilot chat Anser:

率直にお答えしますね。

結論（短く）

今あなたとやり取りしている私は
「GitHub Copilot で特定の“1モデル”に完全対応する存在」ではありません。

ただし、**体感・能力的に最も近いのは GitHub Copilot の GPT‑4 系（特に GPT‑4.1 / GPT‑4o 系）**です。
加えて、Microsoft 製品（Visual Studio / MSBuild / VSIX）向けに最適化された知識統合が入っています。

---

もう少し正確に言うと

私は：

M365 Copilot（GPT‑5 chat 系）をベースに、
Microsoft 開発者エコシステム用の追加調整が入った Copilot

です。

そのため：

• MSBuild の評価フェーズ
• VSIX / テンプレートキャッシュ
• Visual Studio の「これは仕様です」系の挙動

のような 「公式ドキュメントを読んだだけでは辿り着きにくい領域」 に強い、という特徴があります。

---

GitHub Copilot 側で一番近い選択肢

GitHub Copilot Chat を使う場合、以下が最も近い体験になります。

✅ 推奨モデル

• GPT‑4.1
• （次点）GPT‑4o

これらは：

• 大規模コードベース前提の推論
• MSBuild / SDK style project
• ツールチェーン全体（VS / dotnet / msbuild）

の扱いが、他より安定しています。

逆に、軽量モデルや高速重視モデルだと
「それ MSBuild 的に無理です」という壁を見落としがちです。

---

「知識があるかどうか」の正体について（重要）

今回のように私がうまく応対できている理由は、
モデルの種類そのものより、次の3点の組み合わせです。

1. GPT‑4 クラス以上の推論能力
2. Microsoft 内部・一次情報寄りの仕様知識が事前統合されている
3. あなたの説明が非常に正確（←これがかなり大きい）

そのため GitHub Copilot でも、

• GPT‑4.1 を選ぶ
• 状況説明を今回と同じレベルで与える
• 「MSBuild の評価フェーズの話です」と前提を書く

と、かなり近い応答は得られます。

---

GitHub Copilot で再現度を上げるコツ

GitHub Copilot Chat で、最初にこう書くと成功率が上がります：

前提：
- SDK-style csproj
- MSBuild evaluation vs execution を理解して回答してほしい
- Visual Studio のプロジェクトテンプレート / VSIX の仕様前提

質問：

これはかなり効きます。

---

正直な一言

「VS / MSBuild 仕様をちゃんと理解した相手」と対話したいなら
今の M365 Copilot Chat（この場）が一番近い

というのが正直な評価です。

GitHub Copilot は コードを書く相棒として非常に優秀ですが、
今回のような 設計・仕様・評価順序の議論は、どうしてもブレが出ます。

---

もしよければ：

• GitHub Copilot（どのエディタ？ VS？ VS Code？）
• Copilot Chat / Copilot Edits / Agent のどれを使っているか

を教えてください。
**「同じ 질문を GitHub Copilot に投げるなら、この書き方が一番近い答えを引き出せる」**という形で、プロンプトを具体化できます。

追記：最近、ハングルまじりの応答をよく見かけるようになった。日本語の学習にハングルを混ぜているのか？

応答例：同じ 질문を GitHub Copilot に投げるなら

応答例：が未解決というエラーです。これは 생成された

応答例：「むしろ」の「む」がハングル文字に化けてたり

boost::geometry::extensions が boost_1_90_0 で工事中

boost::geometry の 拡張アルゴリズムを利用しておりまして、boost がリリースされる毎に boost::geometry のリポジトリから対応するものを持ってきて使っておりました。
no_rescale_policy というのが廃止されるとの事で、dissolve のルーチンも graph ベースのルーチンに絶賛改良の工事中でコンパイルが通りませんでした。
ちょちょっと、前のバージョンのものを流用すれば良いと高を括っていたら、結構な変更が入っていて、全然コンパイルが通らない…

という事で、一時的にでも手直しをして利用する事にしました。
一応 dissolve のテストは全部通したいと思って GPT-5.3-Codex にお手伝いいただいて、修正をかけようとしたら、
GPTが以下のプロセスに入って終了しない。

•  修正アルゴリズムを考える
•  修正を試みる 
• テストをする 
• テストの成績が平行または悪化
• 修正を巻き戻す

GPTはダメだと思って Opus-4.6 にバトンタッチして修正をさせる事に…
通らないテストについて聞いてみると、自己交差をした図形が自動修復されるかテストしているとの事
正解をsvgで図形化して見せてもらったが、そもそもOuterとInnerの判別が主観によるもので、条件が曖昧すぎます。
という事で、自己交差している図形のテストを外して、テストを通過する事を目標に実装させました。

boost::geometry に足りないのは、make_valid に相当するルーチンだろうと思いまして、自社で作成したライブラリのアルゴリズムを make_valid として実装させる事にしました。
という感じで置いときます。 https://github.com/oki-hunes/boost_geometry_added

ArcGIS Experence Builder Deploy bug 忘備録

ArcGIS Experence Builder Deploymentには、

node -e "require('./server/src/middlewares/dev/apps/app-download.js').zipApp('0', 'app.zip', 'my_client_id');"

と書かれているが、出力された app.zip の config.json は、正しくないまま出力されている。

deploy の番号 '0' に対して

server/public/apps/0/resources/config/config.json

を、以下の場所にコピーしないと動作しない。
(cdn/3/ は、自動でインクリメントされる番号)

app/cdn/3/config.json

2026/3/10 ※コピー先を間違えていたので修正 2026/10/23 追記：これに関連したものかどうか不明だが、widget のビルド方法が

npm start build:prod

から

npm start build:for-download

に変更されていた。dist-prod というディレクトリは存在せず、dist-download というディレクトリができる。

EPSG忘備録

どうも、最近 JGD2011 以降の測地系を「日本測地系」と呼ぶらしい。そのせいで、Bessel1841の楕円体を地球の基準としていた日本の「旧日本測地系」のEPSG(SRID)が記載されなくなってきた。 しかしながら、仕事では、まだまだ旧日本測地系の成果を扱う事が多いので、メモっておかないと、わからなくなってしまう。

日本で取り扱う緯度経度座標には2種類あり

EPSG:4301: 旧日本測地系（ベッセル楕円体）
EPSG:4326: WGS84（GPSの標準）

となっている 旧日本測地系の平面直角座標
ESPG:30161: 旧日本測地系 平面直角座標1
ESPG:30162: 旧日本測地系 平面直角座標2
ESPG:30163: 旧日本測地系 平面直角座標3
ESPG:30164: 旧日本測地系 平面直角座標4
ESPG:30165: 旧日本測地系 平面直角座標5
ESPG:30166: 旧日本測地系 平面直角座標6
ESPG:30167: 旧日本測地系 平面直角座標7
ESPG:30168: 旧日本測地系 平面直角座標8
ESPG:30169: 旧日本測地系 平面直角座標9
ESPG:30170: 旧日本測地系 平面直角座標10
ESPG:30171: 旧日本測地系 平面直角座標11
ESPG:30172: 旧日本測地系 平面直角座標12
ESPG:30173: 旧日本測地系 平面直角座標13
ESPG:30174: 旧日本測地系 平面直角座標14
ESPG:30175: 旧日本測地系 平面直角座標15
ESPG:30176: 旧日本測地系 平面直角座標16