1. 主にAIについて、しゃべる練習
  2. 「GitHubのpublicに公開するか..
「GitHubのpublicに公開するかしないか」
2026-10-25 35:23

「GitHubのpublicに公開するかしないか」

感想

まだ感想はありません。最初の1件を書きましょう!

サマリー

ソースコードをGitHubなどで公開する意義とリスクについて考えます。公開は、きちんと作る動機になったり、OSSのように知識や成果を共有して人と協力したりする意味がある一方、脆弱性への対応や周囲への被害など、AIによってセキュリティリスクが急速に高まっています。AIに短いスクリプトや拡張機能を作らせる方が、既存の他人のコードを使うより早く安全な場合もあり、共有する価値のある範囲は変化しています。さらに、ソースコードだけでなくドキュメント、手順書、プロンプト、方針書などが一体となってAIやツールを動かすため、公開対象をどう考えるかも難しくなっています。短期的には公開を控え、公開する場合はソース、ドキュメント、スキル、Claude MDなどをまとめて公開するという考えが語られます。

ソース公開の意義と自己管理
おはようございます。AIについて喋る練習になります。 今回のテーマは、ソースを公開することの意義や意味やリスクの変化です。
最近、セキュリティが大変でして、いろんなものの脆弱性が発表されては、それに対応しというのを続けています。
今はソースの話を中心として、今回のテーマにしていますが、それでなくても、ネット上に何かアプリみたいな、ウェブサービスみたいなものを公開していると、
脆弱性への対応というものを公開している数だけ、それの対応が発生するリスクと工数がかかってくるということを痛感しておりまして、
現時点においては、公開する量をできるだけ少なくした方がいいのかなと感じています。
元々の話でいうと、ソースを僕が公開する理由は、パッと思いつくので大きく2つありまして、
一つは、ちゃんとしたものを作るということですよね。自分の意識の問題なので微妙かもしれないですけれども、
それでもブログを書いて公開することであったりとか、日常を出すというのも、場合によってはリスクであると思う。
このポッドキャストで自分の考え方とかをしゃべるのもある意味リスクだと思うので、何も出さなければ一番リスクは低いとは思うんですけどね。
ただそれを出すというのと、コワーキングスペースとかで仕事とか勉強をするとか、自分一人で家でいたらダラダラしちゃったりとか、
人の目がなんとなくあるみたいなところでもちゃんとやろうと思っていること、試験勉強だったり読書だったりができるみたいな、そういう点もあったりとか。
あとは同じような志の人が一緒にネットで会ってコミュニケーションしたりとかすることができれば、自分も頑張ろうみたいな気持ちになったりするかもしれない。
あとはずっと家の中にいて、年中部屋着で生活するみたいな。
外に出かけするといったら、ある程度身だしなみを整えて、ちゃんとした格好をして、ひげ剃っていくか、剃ってみたいな。そういうのが働くんじゃないかなと。
あとはずっと家で、自分とか家族ぐらいしかいない空間とかがずっと続くと、そこで片付いていないとか、そういうのがあるけれども、
例えば、時々来客があって一緒に食事しましょうとかね、そういうのがあれば、部屋とか家の中が片付けるということへの優先度が上がるとか、
あとは部屋の掃除とか、きれいにすることで優先度が上がるとか、そういうのがあるかなと思いますよね。
もちろんそんなことは気にせず、できる人はね、あろうがなかろうが家の中は完全に片付いています。ピカピカですという人もいると思うし、
勉強とかもね、完全に自分をコントロールして、きっちり決められた時間に完全に集中して、いらんこと考えずに、
本来やるべきことに全力100%パワーを注ぎ込むことができますという人もいると思うのでね。
人による部分とかがあるかもしれませんが、そういうことは結局自分の能力、何能力、自己管理能力の低さを低いんですよと言っているようなものではあるわけですけれども、
そうなんですが、恥の多い恥をさらしながら生きている人生でございますという感じですが、
そういう作ったものの情報を公開するというのにはそういう意味があるなと思っています。
次の話としては、シェアとか共有したりする文化というのが好きなんですよね。
オープンソースソフトウェア、OSSのコミュニティとかがすごい好きなので、
そういうふうに自分が作ったものを共有する、ちょっと作りすぎたのでお隣さんからもらっちゃいましたみたいな、そういうノリが好きなんですよね。
そもそもの部分として、人と人が力を合わせながら暮らしていく、生きていくみたいな、そういう考え方、だからだと思うんですよね。
これが私の人生の中で培われた性質なのか、一般的な性質なのか、ちょっとよくわかってないですけれども、パーセンテージがあるとは思うんですけれどもですね。
AI時代のセキュリティリスク
ただ、特にAIによる劇的な状況の変化というのがありまして、GitHubとかにソースとかを公開することのハードルの置き方は結構考え方が変わったりする部分ができているかなと思う面もあるんです。
その一つがセキュリティですね。AIって今セキュリティの脆弱性という、新聞とかでは欠陥という表現になっていたりしますけれども、そういうのがあると対応も大変だし、対応が大変という側面もあるし、
実際に問題があってやられることによってこういうような、自分自身がダメージを受けることもあるし、周りの人がダメージを受けたりとか、インターネット環境全体に対して何かダメージを与えることにつながったりとか
ということがあるんですが、そのリスクがかなり急激に高まっていると思うんですよね。
だからそれは公開しない方へのベクトルとなるのかなとは思っています。
これって今は攻撃する側も日々進化するAIに最高のパフォーマンスが出せるように超頑張って攻撃するという感じでギリギリ頑張っているわけですけれども、
攻撃を受ける側がそのモチベーションとスピードに比べたら優先度が低くなったり遅かったりして、
ボーと立っているとも完全にボコボコにされてしまう状態が発生しているわけですけれども、この状況や意識や感覚は変わってくると思うんですよね。
自分が作ったアプリの使っている様々な高い層に分かれているコンポーネントとかプログラム言語とかフレームワークとか、それぞれ一個に引っかかったら対応しないといけないしリスクがあるということでありますけれ
ども、
それぞれが最新のAIで常にセキュリティを改善し続けている脆弱性を見つけてそれを修正していくということができるだけスピーディーにできるだけ省力化でできるようにするということが進んできていると思うん
ですね。
最近もアンスロピック社がそういう感じのOSSに対して調べてくれて、こういうのがあるよって教えてくれたり、こうやって治るよっていうところをまとめて送ってくれたり、そういうところまでやってくれるみたいな。
誰でもできる、使わせてもらえるものではなさそうですけれども、そういう取り組みを始めたりとかしているので、そういうのをやっていくことで改善していくかなと思いますね。
これは僕が住んでいるエリアにもあってですね、昔から1960年代70年代からやっているお店とか建てる建物とか老朽化してきて面倒を見る体制とか人とかもだんだん少なくなっていってギリギリ建てますみたいな。
地震でもありますよね。最近できた建物だったらまあまあ大丈夫でも、ギリ建てますみたいな感じで建てるやつがもう地震が来たらもう全壊してしまうというね、そういうことがあって。
ソフトウェアでも老人化していくっていう感じで予防予防になってかろうじて立ってます、かろうじて息してますみたいな感じだと、そういう台風みたいなものがドワーッとくると、先に言うとコロナとかがドワーッとくると
やられちゃうということがあって。
今この台風が来てて、いろんなちゃんと手が行き届いてないものっていうのがやられちゃってるっていう状況だと思うんですよね。
なのでこれによって、言い方が難しいけれども、新陳代謝が起こる。うちの近所とかでもそういう古いお店、個人経営のお店をやってる人が場合に出たら亡くなりになったりとかリタイアするとかということになって、
っていうお店とかが一旦壊されて、新しい家なりお店とかが立つみたいなことが結構な激しさで起こってますので、そういう感じで変わっていく、入れ替わっていくということだと思うんですよね。
ただそれがある程度落ち着くまでの間、AI2027的には落ち着かなさそうな未来予想図もありますけれども、とりあえずそれを置いといて、今の今日の現実的なと思われる考え方で言うと、もうちょっとしたら落ち
着くかなと思うので、
そうなってくるまでしばらくは公開を控えるという考え方もあるかなと思っております。
AI自作による共有価値の変化
もう一つ公開するしないに影響するなと思っていることとしては、誰でもプログラムを書け、AIが書いてくれる時代になった、そのAIを使える時代になったということで、
これぐらいのものを別に共有しなくても自分で作る、そのAIに作ってって言ったら作ってくれるから、共有するまでもないなって思うラインがぐいぐいと上がってきているなと思いますね。
例えば、最初の頃にAIにプログラムを書いてもらおうの定番としてあったと思うテトリス、テトリスを作るみたいなやつは一撃で作ってくれちゃうわけですけれども、
それをテトリスのゲームのソースを共有しますと言って共有しても、自分でAIにプログラムを使えると言った方が早いわってなる。
他の人が作ったやつを使うリスクっていうのも高まる昨今ですね。
これはAIとはあまり直接ではない部分も多いと思っているんですけれども、
Chrome拡張とかワートプレスのプラグインとか、そういうののリスクとかっていうのは、ちょっとしたものだったら自分で作ったり、何ならAIに書いてもらったりした方が早いし、
そっちの方が安全安心で、全く何もわからない人だと結局AI暴走のリスクが懸念されるかもしれないですけれども、
ある程度ソースを見て、これはヤバそうなソースなのか、大丈夫そうなソースなのかっていうのがわかる人、
もちろんAIにも手伝ってもらって調べられる人とかであれば、
短いね、数十行とか、100行程度のスクリプトとかでも実現できるようなプラグインとか、
単機能、単発のやつとか、Chrome拡張プラグインはAIに書いてもらった方が早い、そして安全と言えるラインもあるかなと思います。
安全か、早いか、いろんなプラグインとか拡張機能とかも、設定でいろんな好みに合わせて、
こういうパターンはこう、こういうパターンはこう、みたいな感じで、場合わけで動いていることによってデカくなっているという側面もあると思うんですけれども、
自分による自分の自分のためのだけのプラグインや拡張機能とかであれば、
そういう設定がいらないんですけど、自分がやりたいことを一本一直線で単機能で作るってなるから、
構造もシンプルでパッと見て何やってるかもわかりやすいものが出来上がるので、それでいいんじゃないかっていうのがある。
そういう意味でも、自分だけのやつをAIに書いてもらうメリットがある方向だなと思っています。
ソースから知識・プロンプトへ
次の話としては、GitHubとかソースを公開共有するプラットフォームっていうのが基本だと思うんですけれども、
最近、ソース以外のものも混ざりながら一体となって存在しているみたいな、そういう感覚がすごいあります。
今に始まった話ではないですけど、ドキュメントとかっていうのも、ソースとしてプログラム言語として実行されるわけじゃないですけれども、
動くものの仕様であったりとか仕組みであったりとか説明であったりとか、そういうものをまとめたドキュメントっていうのがあるし、
さらにそれに加えて、最近のAIのところでは、AIへの説明とか、そしてAIへの指示とか、そしてAIへの手順書とか、
そういうものが、いろんなものがマークダウンと呼ばれる形式で書かれるっていうのがよくある風景だと見ておりまして、
それらをまとめたものが、何かウェブアプリであったり、何かをする存在なんですよね。
これらは全体として一つの塊としての知、ナレッジであり、知性、知能と言えるかなと思ったりします。
それは何かをプログラムとして動かすことができるっていうのもあるし、
それ自体が、最近の言葉でいうとAIエージェントとして、より自律的に動いたり判断したりするっていうこともやろうと思えばできるっていうところにまで来ていると感じています。
なので、ソースかソースじゃないかということは、あまり重要じゃないというか、気がしています。
最近よく見かけるような気がするのが、ソースは共有しないけれども、作り方を共有するというか、
プログラムを書いてもらうときのプロンプトと呼ばれるチャットの会話みたいな、こっちのセリフですね。
プロンプトをこんな風なプロンプトにすればできますよみたいな、やったり共有したりすることがあるなと思うんですね。
これだと環境を吸収してくれたりとか、自分でやりたいようにカスタマイズして再構築したりとかってことができるっていうことですよね。
ソースを共有するというよりもリスクが少ない。
ソースは基本的に自己責任の文化がすごく強いので、この自己責任の文化もよしよしの面があるとも思っているので、
それが問題と思う人もいらっしゃるかもしれないですけれども、自己責任なので、
作る側の立場でいうと、この内容が欠陥があったとしても、それの賠償責任とか責任とかを法的に問われるということはないという主張によって成り立っていると思うんですね。
実際にそれが通るか通らないかという問題は別途あるとして。
公開と権利侵害の境界
公開してもリスクはないと思いますけれども、あとは権利侵害とか言われればリスクがありますね。
AIが作ってくれましたというものが権利的に問題がないソースコードなのか、
既存のソースを丸パクリしているソースなのか、これは著作権侵害となるような行為なのかというのを使っている側が判定することは非常に難しいと思うので、
その辺の難しさはめちゃめちゃいろんなところが難しいような気はしてますけれども。
感覚としては昔というところのソースコードがあって、ソースコードをコンパイルすると実行するプログラムができてみたいな。
実行するプログラムだけを配布すればとりあえずやりたくてはできると。
それの作り方はソースを配布しないとわからないみたいな。
という関係性がソースと実行モジュールの関係性が、
スクリプト言語とかも多いので、ソースとプロンプトの関係にもある程度成り立つ程度があるかなと思ったりしますね。
プロンプトがあればそれをAIに渡すことでプログラム、使えるツールみたいなものを手に入れることができるということができるかなと思います。
ただこのラインもAIが進化したことによって部分的に配ったからといって、
プロンプトを渡せばそこから同じテトリスを作ってプロンプトを共有すればテトリスの動くソースコードが手に入るというのはそれはそうなんですけどね。
先ほどのAIがすごすぎて逆の移行もできちゃうような気がするんですよね。
ソースコードを見ればこのソースコードを書いてくれるプロンプトを書いてくれることができたりとか、
実行モジュールを逆アセンブルというのかな、逆コンパイル?わからないですけど逆算して100%の精度ではないにしてもこういう感じのコードかなみたいな感じでソースコードを再構築してくれるということもできる
みたいな。
今は完璧ではないという話もしてますけれども、AIがすごい勢いで進化しているので、だんだんこれぐらいの精度だったら十分じゃないというような精度になってきたここ1,2年だと私の印象としてはありますので、
少なくとも余談を許さないというか、そうなることもある程度折り込む必要があるぐらいの感覚を持っています。
改めまして言いたいこととしては、公開しないラインがどんどん増えているので公開しないことも多いけれども、少なくとも短期的には、
公開するとすれば全部公開するのがいいんじゃないかなという考え方を僕は持っていてですね。ソースもクロードMDみたいなやつもスキルもドキュメントもまとめて公開するという風に判断することが多いですね。
この辺もまた悩ましい部分もあるのかなと思って、私がやってるようなことは全然そんな悩ましさは少ないことが多いですけれども、中にはね、でもちょっと悩ましいなと思うのもあるんですけれども、
こういうので思い出すのが、無線関係の雑誌とかで、盗聴の表現とか怪しいですけど、盗聴されてしまうぞみたいな感じの言い方をしつつ、
実際に盗聴のやり方がめちゃわかりやすく書かれているみたいな、そういうイメージ。
あと昔ネットランナーだったかな。そんな雑誌があって、それでインターネット上で、黒だったりグレーだったり脱法状態だったりするけれども、
結構やばい感じのことをやり方みたいなやつをお伝えしているような、そういう雰囲気を感じることがありましたけれども、
そういうのもね、実際に問題のある行為自体をするわけではないけれども、そのやり方を教えるっていうことが、
ソースは共有しないけれども、プロンプとは共有するっていうくらいに近くさを感じたりするんですよね。
ただ、イコールでは全然ないし、これ本当にどういうものを共有するのかっていうことによって全然意味合いは変わってくる。
ホワイトハッカーとブラックハッカーは全然違うみたいなぐらい大きく違うんですけどね。
それがどういう行為なのかっていうことを判断することはなかなか一筋縄ではいかないし、
出す側がどういう気持ちなのかっていうところを、さっきの無線の雑誌とかもそうですし、
そこをどう押し測るのか、その表面的に書いてあることと、実際の実態っていうところはどうなのかみたいなところを正しく把握するっていうことはなかなか簡単ではないよなと思ったりもします。
ソースコードの役割の変化
さらに追加して、どんどん増築増築でしゃべりますけども、追加として思うこととしては、
AIね、一般市民的な意味でAI、チャットGPDが出てきて会話するみたいなテキストチャットっていうところからスタートして、
プログラムを書いてくれるやってなって、プログラムを自分のパソコンもどんどん操作しながらどんどん書いてくれたり、
パソコンの作業とかも、最初はコマンドラインとかからやってくれ、だんだんブラウザーとかも操作しながらやってくれみたいな感じで操作してくれるとなってきていますけれども、
今の時点でソースコードを書くっていうところのラインはどんどん溶けていっている感じなんですよね。
その先にある何らかの課題を解決するとか、やりたい、こういう風にしたいのに今できないとかめんどくさいとかっていうことを、
より簡単にできるように、自動的にできるようになったりするっていうことを実現するっていうラインでAIが使えるツールになってきていて、
最近とかは一応やりたいことごとにディレクトリを作ってそこでクロード立ち上げてみたいな感じでやってて、
これもかなり古臭いやり方ではあるなと思いながら、ターミナルでやってますけれども、
そこで言うことって、もうこういうプログラムを書いてくれじゃないんですよね。
こういうことをしたいんだけれどもどうやったらできるかちょっとお考え、交談に乗ってほしいみたいな感じでディスカッションするんですね。
それによってソースコードが最終的に書かれることもあるし、書かれないことも結構あるんですよね。
AIに対する指示も全部ソースコードを実行する形じゃなくて、
AIが考えて何か作業をするみたいなことだけで終わるケースも結構あります。
その中で単純作業度が多かったりとか、時間をより短くするとか、
よりAIの負荷、トークンを消費しない形にするとか、
そういう目的を達成するためにソースコードをAIが書いた方が良さそうですね。
書いたらだいぶ楽できますわと言われれば書くみたいな。
そうでもなかったら別に書くか書かないかは依頼する側の僕としてはある意味どっちでもよくて、
その中でAIが判断して書いたり書かなかったりするという段階になってきていると思うので、
そういう意味でもソースっていうものはそこを切り取るっていうことがウェイトとして下がってきていると感じます。
公開を控えるという結論
ということで改めてまとめると、いろいろな思いがあって僕としてはソースをできるだけ公開したい、
作ったものは全部公開するぐらいの勢いでやってきたしやりたいと思っているけれども、
セキュリティの懸念があるので、進むのも短期的には控える方向、
パブリックじゃなくてプライベートにしていく方向っていう方向にした方がいいと感じていると。
その対象としてはソースコードだけじゃなくて、
ドキュメントであったり手順書、スキルと呼ばれる人間に分かる言語で書かれた手順書みたいなものであったり、
方針とか考え方とかプロジェクトのポリシーみたいなものをまとめているクロードMDとか呼ばれる方針書みたいな、
方針まとめみたいなそういうものを一式として公開するときは公開するということですね。
これが今回の喋ろうと思っていた内容になります。
では今回の喋れんは以上です。ではまた次回。
35:23

コメント

スクロール