2026年9月19日土曜日

Instance13速度計測

 COPT Barrier 8.03 RTX4060TI Super GPUで367secになっていました。



古いデータですが、ルーベンカトリック大学のPieter Smetさんが計測結果では、12000秒程度なのでこちらも世界最速で間違いないと思います。

2026年9月18日金曜日

Claude code は、GPL コードを改変できるか?

 Claude code は、GPL コードを改変できますか?


Claude Code で GPL(GNU General Public License)のコードを改変することは、技術的に可能であり、ライセンス(法的なルール)上も認められています。
ただし、改変したコードをどのように扱うかによって、GPL の「コピーレフト条項」が適用されるため注意が必要です。
技術面とライセンス面における重要なポイントは以下の通りです。
1. 技術的には自由に改変可能
Claude Code は、ローカル環境のファイルに直接アクセスしてコードの編集やリファクタリングを行う AI エージェントツールです。対象のコードが GPL であっても、他のライセンスであっても、プロンプトで指示すれば通常通りファイルの書き換えや機能追加を実行できます。 [1]
2. ライセンス(GPL)上の注意点
GPL コードを改変すること自体はライセンスで許可されていますが、改変したコードを外部に公開・配布(または製品に組み込んで販売)する場合は、GPL の厳格なルールが適用されます。
  • ソースコード公開の義務(コピーレフト):
    GPL コードを少しでも改変して(または組み込んで)作ったソフトウェアを他者に配布する場合、そのソフトウェア全体のソースコードを GPL ライセンスで無料公開しなければならないという義務が生じます。
    [1, 2]
  • AI が書き換えても「GPL」は引き継がれる:
    「人間ではなく AI(Claude Code)に書き直させたから GPL の縛りから逃れられる」と考えるのは危険です。実際に、AI を使ってコードを書き直してライセンスを変更しようとした事例(chardet事件など)が議論を呼んでいますが、元の GPL コードの構造やロジックを大幅に流用している場合、法的・倫理的に著作権侵害やライセンス違反に問われるリスクがあります。
    [1, 2, 3]
3. Anthropic 社の利用規約
Anthropic 社の規約上、Claude Code が出力したコード(Outputs)の所有権は利用者にあります。そのため、商用利用すること自体は規約上問題ありませんが、それが元々 GPL だったコードをベースにしている場合は、上記の通り「GPL のルール」が最優先されます。 [1, 2]

💡 まとめ
  • 社内や個人でクローズドに利用・改変するだけであれば、GPL を気にする必要はありません
  • 改変したコードを外部に配布・公開したり、自社の商用サービス(※配布型)に組み込んだりする場合は、全体を GPL で公開する必要があるため注意してください。 [1, 2]

chardet事件とは?

chardet(シャーデット)事件とは、2026年3月に発生した、「AIを使ってオープンソースソフトウェア(OSS)を一から書き直し、ライセンスを変更することの是非」を巡る、テック業界を揺るがした大きな論争(事件)のことです。 [1, 2]
Pythonの非常に有名な文字エンコーディング検出ライブラリ「chardet」の現メンテナーが、Anthropic社の Claude Code などのAIを活用してコードを完全に再実装し、ライセンスを「LGPL」から「MIT」へ変更したことから始まりました。 [1]
この一連の出来事は、AI時代における「ライセンス・ウォッシング(ライセンス洗浄)」の初の大規模な実例として大きな波紋を広げています。 [1]

🛠️ 事件の経緯
  1. 背景とメンテナーの目的
    • chardet は月間1億回以上ダウンロードされる超重要ライブラリです。元々はLGPLライセンス(改変した場合は同じLGPLでソースコードを公開する義務があるコピーレフト系)でした。
    • 現メンテナーのダン・ブランチャード氏は、長年このライブラリをPythonの標準機能(標準ライブラリ)に組み込みたいと考えていましたが、LGPLという厳しいライセンスがその障壁になっていました。 [1, 2, 3, 4, 5]
  2. AI(Claude)による5日間の大改造
    • 2026年3月、ブランチャード氏は元のソースコードに直接アクセスせず、APIの仕様やテストコードだけをAI(Claude Code)に与え、わずか5日間でコードを一から再実装(バージョン 7.0.0)させました。
    • 結果として、処理速度が48倍に向上し、コードの構造的類似性も1.3%未満という「完全に新しいコード」が完成しました。
    • メンテナー側はこれを「独立した新規の著作物」と主張し、ライセンスを制約の緩いMITライセンスへ変更してリリースしました。 [1, 2, 3, 4, 5, 6]
  3. 原作者の「復活」と猛抗議
    • リリース直後、2011年にインターネット上から姿を消していたはずの chardet の原作者マーク・ピルグリム氏が突如GitHub上に現れ、「再ライセンスする権利などない。LGPL違反だ」と猛抗議のイシュー(問題提起)を立てました
    • 原作者側は「彼らは元のコード(LGPL)を熟知した上で開発しており、AIを使って一から書き直したと主張しても、元のコードへの依存性(依拠性)がある以上、これは派生物でありライセンス違反だ」と主張しました。 [1, 2, 3, 4, 5]

⚖️ なぜこれが大問題(事件)になったのか?
この事件が単なる開発者同士の喧嘩にとどまらず、世界中で議論されているのには3つの大きな論点があるからです。
①「クリーンルーム設計」の前提崩壊
従来、法的にライセンスを回避して同じ機能のソフトを作るには、元のコードを一度も見たことがない開発者が仕様書だけを頼りに一から作る「クリーンルーム設計」という手法が使われていました。しかし、今回は「元のコードを知っている人間が、AIをプロンプトで操って一から出力させた」ため、これが法的にクリーンと言えるのか強い疑問が呈されています。 [1, 2]
② ライセンス・ウォッシングの懸念と法的なグレーゾーン
AIによる再実装が認められると、厳格なオープンソースライセンスが容易に緩いライセンスへ「洗浄」され、OSSの信頼基盤が脅かされる恐れがあります。また、AI生成物に著作権が成立するかや、翻案権の侵害にあたるかについて法的な意見や判例が分かれています。 [1, 2]

2026年9月17日木曜日

The Significance of Solving Instance 24 - インスタンス24が解かれた意義

 Although I cannot strictly claim to have “solved” the problem without a formal proof of optimality, let us allow ourselves to say it is solved, given that the LB–UB gap is only 0.00247%.

For decades, the nurse scheduling problem has been treated as a textbook example of NP‑hardness. The common belief has been simple: because it is NP‑hard, obtaining exact optimal solutions is essentially infeasible. Textbooks and academic literature have repeated this narrative, and even today most of them focus on approximation methods and metaheuristics rather than exact approaches.

NP‑hardness tells us that as the problem size grows, solving it within a reasonable time becomes difficult. But the theory says nothing about what that “absolute size” actually is. It certainly does not claim that real‑world NSP instances must be impossible to solve.

We NSP researchers have spent years trying to understand where that boundary truly lies—or to push it further. Now that the largest instance in history has been solved, it becomes harder to rely on the old excuse that “real‑world NSPs are NP‑hard, so of course we cannot obtain optimal solutions.” This does not mean that every real‑world NSP will suddenly become solvable, but it does suggest a small paradigm shift. After all, every academically published benchmark instance has now been solved. At the very least, textbooks will need to be updated.

For INRC1 and INRC2, all optimal solutions have been obtained. For Scheduling Benchmarks, the final remaining instance has been solved with a gap of only 0.00247%, essentially optimal. With this, I consider the long‑standing goal of solving all academic benchmark instances to be complete. (The pursuit of GAP = 0% is left to future researchers.) It has taken nine years since my presentation at RAMP. Back then, none of INRC2 and only about half of Scheduling Benchmarks had been solved. It is thanks to the achievements of pioneers such as Tim Curtois, and the advanced capabilities of the COPT Barrier Solver, that we have finally reached this point. This long challenge now comes to an end.

Finally, I close this post with gratitude to my wife, who supported me without complaint through a challenge whose feasibility was never guaranteed—something that would never be tolerated in a private company.


Optimality証明が出来ていないので解けたとは言えないのですが、LB-UB=GAP=0.00247%に免じて解けた、としましょう。

今までナーススケジューリング問題は、NP困難の代表的問題とされて、NP困難だから、完全な最適解を得ることは困難だ、というのが一般的常識でした。実際、組み合わせ最適化関連の教科書や文献では、そのような記述がされてきて、今でも教科書は、厳密解を目指さない近似解法、メタヒューリスティクス的解法の紹介が主です。

NP困難は、規模が大きくなれば、やがてReasonableな時間内に解くことは困難な問題である、ということです。しかし、理論は、その絶対規模については、何も表明してはいません。現実の市井のNSPがそうである、とは言っていないのです。

私達、NSP研究者は、その限界がどこにあるかを知りたい、あるいは、その限界を少しでも遠くにやりたい、ということを糧にして研究活動を行ってきました。

今回、史上最大規模の問題が解けたからには、市井のNSPが、NP困難だから解けなくて当たり前(最適解は分からなくても当然)、という一般常識や言い訳が、言いにくくなった、ということです。もちろん、全ての市井のNSPがただちに解ける、ということではありませんが、これまでの一般常識を少しだけパラダイムシフトする効果はあるかもしれない、という意義があります。論文として公表されているすべてのアカデミックベンチマークは解けたのですから。少なくとも、教科書は、修正する必要があるでしょう。

INRC1,INRC2については、全ての最適解、SchedulingBenchmarsについては、最後の1問についてGAP=0.00247%とほぼ最適解を得ることが出来ました。これで、アカデミックベンチマークを全て解く、という目標は完遂したとします。(GAP=0%については、後進に託します)RAMPでの発表から実に9年を要してしまいました。あの当時、INRC2は全問、SchedulingBenchmarksは、半分程度しか解かれていませんでした。Tim Curtoisさんら先人の業績や、COPT Barrier Solverという先進のソフトウェアがあって初めてここまで来ることができました。永い挑戦もこれで終わりです。

最後に、民間企業ならば、到底許されることはない、実現できるかどうかわからない挑戦に対して、文句も言わずにずっと支えてくれた妻に感謝し本稿を閉じます。



2026年9月16日水曜日

インスタンス24世界記録更新

 記録更新されました。

Changes



Timさんから、返信を頂きました。

Dear Tak Sugawara-san,


I have just updated the benchmarks website.


It really is an impressive result. The largest instance is now very close to 

being solved to proven optimality. I always thought it would be solved one 

day, but not so soon!


I haven't got a copy of the working paper you mentioned but here are the 

authors' email addresses:

私の返信です。

Tim-san,


Thank you for the update.


Regarding “but not so soon!” — I completely agree.

For more than a year I’ve been continuously inventing and testing countless approaches to solve this instance. Its scale is truly exceptional, and ordinary methods simply cannot reach this point. Hardware and software will certainly continue to advance, but I still expect that this instance will likely remain unsolved for at least the next decade.


Thank you also for providing the authors’ contact information. I will reach out to them.


Best regards,

Tak. Sugawara

2026年9月15日火曜日

今井さんのソルバDocumentがUpdateした

 CDCL を用いた MILP の厳密解法 - Speaker Deck

2年ほど前に拝聴した資料からUpdateしたようです。Bendors DecompositionとSATソルバを使うところが新しい試みで汎用MIPソルバとして数少ない公開ソルバの一つ(CBC並みの性能を持つソルバとして日本では唯一の公開ソルバ)です。

2026年9月14日月曜日

CLAUDE CODEに移調を依頼したら断られた

 最近、CLAUDE CODEにいろいろお願いしています。その一つに楽譜を読み込んで、移調してもらう、という作業をお願いしてみました。


結果は、御覧の通りで断られました。もちろん正式に購入した楽曲PDFを渡しており、個人として愉しむために行っているのですが。

去年までのAIは、依頼を断ったりすることはなかったと思います。人間界のルールを順守するということは、技術としての知的所有権を保護するために必要なことでもあるので、ある意味安心方向に進化している、とも言える、と思います。

同じように、所有する知的所有権のコードを勝手に複製コピーされたらソルバ開発業者はお手上げです。その意味で正しい方向だと思います。ちなみに、特許有効期間は20年です。(著作権は70年)



2026年9月13日日曜日

「シフト名が重複しています」 コンパイルに失敗する

 Q. 次の病休:個別事情のエラーが出てしまいます。


Ans.このエラーは、古いプロジェクトファイル(以前のバージョン(恐らくは2023以前))を読み込んだ際、シフト名と内部のスタッフプロパティ名との重複がある場合に発生します。

スタッフプロパティ:

シフト定義:
同じ名前は、最近のバージョンでは許容していないためにエラーとなります。

この例の場合、シフト名の「病休」とスタッフプロパティの「病休」が同じためエラーとなります。


解決策は、名前が重複しないようにすることです。例えば、次のようにスタッフプロパティを変更します。Ex.病休→病休事情