Pythonにおいては、デプロイ用パッケージの最適化は不要なの？

経緯

PythonでPytest導入の記事を幾つか読んでいたところ、テスト用に仮想環境を作成しましょう、といった説明が見当たらなかった。
この作業は必須と思っていた私にとっては、かなり意外な結果だった。

ひょっとして、Pythonではメイン用／開発テスト用で個別に環境を用意すること。それにより、デプロイ用のパッケージ内にテスト用ライブラリの混入を防ぐように取り組むことは一般的ではないのかもしれない。

そうした取り組みを不要なのか？について考えを整理するため、ChatGPTに向けて壁打ちを行った結果を備忘録としてここに記録する。

ChatGPTとの壁打ちの結果

あなた

■私の認識
Javaやnode.jsなどではtest用、メイン用で必要ライブラリの設定を分けるのが一般的だと私は認識している。 例えば、node.jsではpackage.jsonというファイルで依存ライブラリの設定を管理するが、このファイルの中にはメイン用のdependenciesと開発（テスト）用のdevDependenciesの項目が分かれており、必要ライブラリの定義とデプロイパッケージの作成をメイン用／開発テスト用で個別に実施することが可能になっている。 JavaのWebフレームワークなどでも、mainとtestで別個のフォルダを作成し、ライブラリ定義、デプロイパッケージ作成を個別に記述するのが一般的であったと記憶している。 このような「メイン／テストで個別に設定の用意すること」により、テストに使用する単体テストのライブラリやモックライブラリがメイン用のパッケージに混入することが避けられると認識している。

■Pythonにおけるメイン／テストの環境設定
一般的にPythonにおいてはどうだろうか？ メインとテストで個別にフォルダを用意する。個別にrequirements.txtを用意する。開発テスト用のライブラリが混入しないようにデプロイ用パッケージを作成する。 そうした取り組みは一般的に広く行われているのだろうか？ 具体的には下記のような取り組みは行われているのか？か？ ・取り組み1.メイン用と開発・単体テスト用とをフォルダ分けする ・取り組み2.メイン用と開発・テスト用とで個別の仮想環境を用意する ・取り組み3.デプロイ用パッケージの作成はメイン用の仮想環境から実施し、テスト用ライブラリが混入しないようにする googleで簡単にヒットするような初心者向け記事（昨今においては、それは子供だましの質の低い記事を意味することが多い）においては、こうした取り組みは行われていないように見えているので、判断に迷っている。

■質問
質問1.前述の「私の認識」に誤りはないだろうか？
質問2.Pythonにおけるメイン／テストの環境設定に書いたような取り組み1〜3.はPythonにおいては広く行われているのだろうか？取り組み1.〜3.の各々について教えてほしい
質問3.Pythonにおけるメイン／テストの環境設定に書いたような取り組み1〜3.はやるべきだろうか？取り組み1.〜3.のそれぞれに対して、実施した方が良いという根拠、実施する必要はないという根拠を列挙して欲しい

 

ChatGPT

質問に関して、それぞれ回答します。

質問1: 「私の認識」について

• 回答: はい、あなたの認識は正しいです。多くのプログラミング言語やフレームワークでは、本番（メイン）環境と開発（テスト）環境の依存関係を分けることが一般的です。これは、本番環境に不要な開発用の依存関係を混入させないために重要です。

質問2: Pythonにおけるメイン／テストの環境設定

1. 取り組み1: メイン用と開発・単体テスト用とをフォルダ分けする

   • 広く行われているか: はい、多くのPythonプロジェクトでは、ソースコードとテストコードを別々のディレクトリに配置することが一般的です（例えば、src と tests）。

2. 取り組み2: メイン用と開発・テスト用とで個別の仮想環境を用意する

   • 広く行われているか: はい、しかしプロジェクトやチームによって異なる場合があります。個別の仮想環境を用意することは、環境間の依存関係を明確に分離し、衝突を防ぐのに有効です。

3. 取り組み3: デプロイ用パッケージの作成はメイン用の仮想環境から実施する

   • 広く行われているか: はい、本番環境用のパッケージを作成する際には、開発やテスト用の依存関係が含まれないようにすることが重要です。

質問3: 取り組みの必要性について

1. 取り組み1: フォルダ分け

   • 実施すべき根拠: ソースコードとテストコードの明確な分離により、プロジェクトの構造が明確になり、保守性が向上します。
   • 実施不要の根拠: 小規模プロジェクトの場合、フォルダ分けによる複雑性の増加が逆に管理を難しくする可能性があります。

2. 取り組み2: 個別の仮想環境

   • 実施すべき根拠: 環境間での依存関係の衝突を避け、開発と本番の環境を明確に分離できます。また、環境ごとの問題の特定が容易になります。
   • 実施不要の根拠: 仮想環境の管理は追加の作業となり、プロジェクトの複雑性を高める可能性があります。

3. 取り組み3: デプロイ用パッケージの作成

   • 実施すべき根拠: 本番環境に不要な開発・テスト用の依存関係を含めないことで、パッケージのサイズを最適化し、セキュリティリスクを低減します。
   • 実施不要の根拠: 環境ごとのパッケージ作成は追加の手間となり、小規模なプロジェクトや簡単なスクリプトでは過剰な設定となる可能性があります。

これらの取り組みは、プロジェクトの規模や複雑さ、チームの作業フローによって異なります。大規模なプロジェクトや厳密な環境分離が求められる場合には、これらの取り組みが推奨されますが、小規模プロジェクトでは柔軟なアプローチが適している場合もあります。

 

 

資料チェックメモ「人工知能研究の新潮流2 ～基盤モデル・生成AIのインパクト～」

## 資料

- 人工知能研究の新潮流2　～基盤モデル・生成AIのインパクト～｜戦略提案・報告書｜研究開発戦略センター（CRDS）
  - https://www.jst.go.jp/crds/report/CRDS-FY2023-RR-02.html

## 第4世代AIのまとめ（状況、独自AI開発の理由、提言）

「所感」

技術視点というより政策提言という視点で記述されたもの

- 日本にとっての状況認識まとめ

 ● 対話型生成系AIの進化が、人間の知的作業全般に急速な変革をもたらし、
    産業、研究開発、教育、創作などさまざまな分野に幅広く波及しつつ
    ある。その開発・活用が、人や組織の生産性向上に直結し、
    国の国際競争力を左右する。
  ● 一過性の話題ではなく、大きな変革期の始まりと認識して迅速に
    対応すべきであろう。日本でも対話型生成系AIの活用・応用開発が
    積極的に展開されており、産業・経済の活性化につながるとの期待がある。
    政府の政策面でも迅速・活発な検討が始まっている。
  ● 大規模モデルは学習1回に億円超の計算費用がかかるため、
    Big Tech企業で構築したものをAPI利用しているのが現状である。
    この中核汎用技術を海外APIに依存することは、経済安全保障面および
    科学技術政策面でリスクになる。API利用対価を払い続ける負担も大きい。
  ● API利用では、応用開発は進めることができても、知能モデルの
    解明・探究というAIの基礎研究において大きなハンディキャップを負う。
    学習させるデータや出力の良否判断は国の価値観・文化を反映するので、
    海外API依存はその判断の自立性を手放すことにつながる。

- 国内で独自AIを開発、保有する理由
  ● 経済安全保障面でリスクがある（さまざまな産業の生産性向上が
    他国のシステムに依存する）
  ● 科学研究の国際競争力の相対的に低下する（競争力の基盤を他国に
    依存する）
  ● 知能モデル・AIの基礎研究でハンディキャップを負う（API利用のみの
    研究では限界がある）
  ● 国の価値観・文化に関わる判断の自立性を手放すことになる（他国の
    価値観に染まる）

- 提言

  - ChatGPTなど既に広く使われている極めて大規模な基盤モデルに、
    今から追いつくことは難しいが、
  - 上記リスクを考えるならば、何らかの国産基盤モデルを開発・維持
    していくべきであろう。

## 『AIソフトウェア工学』についてのまとめ

- まとめ

  - 機械学習がソフトウェア開発にパラダイム転換を起こす。
    機械学習を前提としたのが「AIソフトウェア工学」
  - 従来の演繹型開発（プログラムを書く手法）から、
    機械学習を用いた帰納型開発へと進展していく
  - この工学は、AI向けの帰納型システム開発に対応する拡張技術
    体系・方法論として位置づけられ、国内では「機械学習工学」、
    海外では「Software2.0」とも呼ばれる
    2017年後半から、この工学は海外でも新しいパラダイムとして
    認識されている

読書メモ『ファンをはぐくみ事業を成長させる 「コミュニティ」づくりの教科書』 第1章ビジネス・コミュニティを立ち上げる

経緯

VRChat内のエンジニアコミュニティで、週一の読書会を実施している。読んだ本の読書メモをこちらにアップしていこうと思う。

読む本を探す／選ぶのに参考になるような情報を記載したい。

前回に引き続き、読んだ本は『ファンをはぐくみ事業を成長させる 「コミュニティ」づくりの教科書』

前回の記事はこちら ↓ （第5章.コミュニティの成果を評価する）

devsetagaya.hatenablog.com

本の概要

この章ではビジネスコミュニティを実際に立ち上げる際に何をやるか、どの点に注意すべきかを具体的に説明している

今回読んだ章は「第1章 ビジネス・コミュニティを立ち上げる」

3ステップでビジネス・コミュニティをつくる

下記の3ステップでコミュニティを作る

•   Step1.方向性を決める（ビジョンやターゲット）
•   Step2.具体的な企画を立て計画に落とし込む
•   Step3.参加者を集める

Step1.まずは方向性

• ある程度具体性を持たせた方向性を設定すること
• コミュニティ参加を通して参加者がどのようなことを実現できるようになるのかを明確にする
  • 例
    • 「自社製品の価値を理解し、周囲に広げてくれるようなコミュニティを作りたい」
    • 「エンジニアが気軽に議論できる場を作り、社内の枠を超えた着想のきっかけをつかむこと」
• 進め方の例
  • 関係者に問いかけながら決める
  • 例
    • 社内で議論し「自社の信頼感を武器に、楽しく健康な体づくりのできるコミュニティを作ろう」という方向になった
    • しかし、前述のビジョンをもとに再び商品の利用者に調査を実施すると、コミュニティのビジョンは「健康づくりを100倍楽しくする」と修正された（商品の利用者に調査を行うことで、コミュニティ参加者に共感できるビジョンになった）
• 注意ポイント
  • 最初につくるビジョンは大切。あらゆる意思決定の判断基準になる
  • ビジョンがあいまいだと短期的な売り上げアップばかりを追い求めたコミュニティになる。大切な長期的な課題解決が後回しになりコミュニティが衰退していくことになりかねない
  • コミュニティ運営者は常に「何のためにやっているのか」という方向性を見失わないようにする。コミュニティを取り巻く環境が変わったときに必要性をきちんと説明できなくなる

Step2.企画して計画する

• 誰に向けた企画か？を明確にする
• ビジョンが明確なら企画はすんなり決まる
• コミュニティの対象を絞るときには、ビジョン作りでヒアリングした自社の製品やサービスの熱心なユーザが役立つ

Step3.参加者を集める

• 本書には明確な解説がなかったが、おそらく下記のようなことを著者は考えているのだと推測される
  • 後段のイベントとコンテンツが参加者を募る手段になる
  • イベントとコンテンツの年間実施計画を立てることで参加者の募集についての具体的な計画を作る

イベント

• 目的を明確にして狙ったターゲットを適切な規模で集めること
• コミュニティの成熟段階や使えるリソースを考えながらコミュニティの全体像を決めていく
• イベントの狙い2つは、
  • 1.コミュニティ参加者と積極的にコミュニケーションをとること
  • 2.コミュニティのビジョンを発信し、賛同者、協力者を見つけること

イベントの規模と特徴

• a.ミートアップ：（4～20人）
  • 特徴：参加者が顔の見えるコミュニケーションをとれる規模
  • 目的：参加者が互いに顔の見えるコミュニケーションをとり、帰属意識を高める
• b.小規模イベント（20～50人）
  • 特徴：ワークショップ、複数登壇者のトークセッションが向く規模
  • 目的：常連と新参、外部からのゲストとコミュニティ参加者。様々な参加者の交流を通じて活動の熱量を上げる
• c.中規模イベント（50～200人）
  • 特徴：トークセッションが向く。登壇者との距離はあるものの良いテーマの登壇者が出演すれば集客しやすくなる
  • 目的：新たなコミュニティ参加者を増やす。
• 大規模イベント（200人～）
  • 特徴：カンファレンス
  • 目的：コミュニティの活動を対外的に伝える。「世の中を効果得たい」というメッセージを発信し、結束を強める

イベント規模における考慮ポイント

• 初年度は中規模イベントを年に1回開催することを最終ゴールに設定するのも良い。それに向けて小規模イベントを年3～5回程度開く
• イベント登壇をきっかけに影響力のある人々とつながれば、その先もコミュニティ活動に協力してもらえることも期待できる
• 小・中規模のイベントはコミュニティの結束を強めるという効果もある
• 大規模イベントはコミュニティの体力がついてから開く。2、3年後に開くイメージ

イベント形式は下記がある

• 「1対n型/LT型」：双方向性は低い
• 「トークセッション型」：特定テーマについて話す場合、効果が高い。質疑が盛り上がれば熱量を上げることができる
• 「ワークショップ型」：
• 「ハッカソン・アイデアソン型」：その企業の製品やサービスに長時間向き合うため、ビジネスイベントに向く

コンテンツ

イベントに参加できない人に向けてイベントの様子を伝え、疑似体験してもらうのがコンテンツの狙い

コンテンツの種類

• 「レポート記事」、「Twitterつぶやきまとめ」、「イベント動画配信」、「Facebookグループの作成等」
• 動画配信については、事前に登壇者から配信許可を得ておくこと

■イベント、コンテンツの計画

それぞれの活動がコミュニティの目的に収れんするように設計する

年間スケジュールの立て方

• 1.リソース（人員、予算、時間）とイベントの規模、準備期間を参考にイベントの規模と開催頻度を決める
• 2.各イベントの形式を決める
• 3.イベントとイベントの間にコミュニティ参加者とどう交流するのかを考える
• 4.年間スケジュールを作成し、それぞれの企画が流れになっているか確認
• 5.年間スケジュールを確定

1年目は運用体制を整えることに専念する

参加者を集める

• コミュニティに興味を示しそうな熱心なファンに声をかけるところから始める。
• B2Cであれば製品・サービスの愛用者を中心に参加者を募る。
• B2Bであれば既に付き合いがあり、面白がってくれそうな顧客企業の担当者に声がけする

具体的な集め方

• 1.最初はおよそ10人を目安に声がけ
• 2.5～10人規模のミートアップを開く
• 3.ミートアップで製品やサービスについてヒアリング
• 4.,友人、仕事上、付き合いのある人など輪を広げる.
• 5.SNSで参加者とつながり、コミュニケーションを続ける

他のコミュニティを見学する

• 先輩コミュニティ運営者の動きを、参加者として体験する
• どのようなコミュニティが理想的かイメージがまとまってくる

所管

コミュニティといってもイメージしにくい方が多いのではないか。

そうした場合、実際に運営されているコミュニティに参加してみることを強くお勧めする。

複数のコミュニティに数か月程度参加してみると、どのようなコミュニティであればメンバーが積極的に参加してくるのか、それは企業にどのような効果をもたらしそうなのか、イメージが浮かんでくる。

 

読書メモ『ファンをはぐくみ事業を成長させる 「コミュニティ」づくりの教科書』

経緯

既存のエンジニアコミュニティの中で新たに定期読書イベントを実施することになった。
良い読書会ありません？いっそ自分でやろうかと、とコミュニティの主催者の方にお聞きしたら、ちょうど興味を持っていたとのこと。幸運が重なり、定期イベントを実験開催することになった。嬉しい。

週1回程度で読書会で読んだ本の読書メモをこちらにアップしていく。読む本を探す／選ぶのに参考になるような情報を記載したい。

今日の本は『ファンをはぐくみ事業を成長させる 「コミュニティ」づくりの教科書』

ファンをはぐくみ事業を成長させる 「コミュニティ」づくりの教科書

本の概要

今日読んだ本は『ファンをはぐくみ事業を成長させる「コミュニティ」づくりの教科書』という本。

著者は河原 あず、藤田 祐司のお二人。藤田 祐司はイベントコミュニティのプラットフォームサービスPeatixの創業者。

この本の特徴として「ビジネスに生かすコミュニティづくりにフォーカスしていること」、「具体的に実践的な内容が語られていること」が挙げられる。

想定読者

想定読者は下記の5パターン。

1. （広報）企業でコミュニティづくりやイベント運営、コンテンツ配信などを任された人
2. （マーケ）消費者との関係構築が必要なマーケティングやブランディングの担当者
3. （営業）顧客同士をつなげるようなコミュニティづくりを任された営業担当者
4. （新規事業）新規事業の開発担当者
5. （自治体勤務）地方自治体で地域の活性化やイベント企画、町おこし、企業誘致に関わる担当者

今日読んだ章は 「第5章.コミュニティの成果を評価する」

概要

前述のとおり、この本はビジネスにフォーカスしている。
ビジネスでコミュニティ作りとなれば、費用対効果を説明するという難しい作業がついて回るが、このテーマについて具体的にサンプルのKPIを紹介してくれている

コミュニティ作りの目標

コミュニティの最終目標は売り上げ増ではないと著者は断言する。
いきなり売り上げ増、イベントの開催数、動員数の増加でKPIを設定するとたいていは苦しい結果に終わるとのこと。

長期的に売上高、利益をじわりと伸ばすという目標を推奨している。

KPIの立て方

ブランディングのKPIについては5種類のカテゴリがあるという。

これらのカテゴリについて複合的にKPIを設定することをこの本はおすすめしている。

1. ブランディング
2. エンゲージメント
3. インフルエンサー
4. コラボレーション
5. 営業

各カテゴリにおけるKPIのサンプルも紹介されている。

1.ブランディングのKPIでいえば、「メディア掲載数」、「SNSの反応数」、「ブランドへのリーチ数（PV）」の3つ。

今日はそこまでで時間切れ。

所管

具体的、実践的な点で役立ちそうな一冊。
じっくりと読み込むというよりは、まずは一通り目を通しておきたい。

画像自動生成AIと著作権についてのSTORIA法律事務所の記事についての備忘録

学習メモ

Midjourney、Stable Diffusion、mimicなどの画像自動生成AIと著作権 | STORIA法律事務所を読んで、備忘録として要点を記述

• 2 第1　論点の全体像
  • 論点には下記の3つがある
    • 論点1.「AIソフトウェアを生成するために他人の画像や文章などの著作物を勝手に収集して利用することができるか」
    • 論点2.「自動生成された画像に著作権が発生するか」（論点2）
    • 論点3.「学習に用いられた画像と同一の画像が『偶然』自動生成された場合、著作権侵害に該当するか」
• 3 第2　論点1「AIソフトウェア を生成するために他人の画像や文章などの著作物を勝手に収集して利用することができるか」
  • AIソフトウェア を生成するために他人の画像や文章などの著作物を勝手に収集して利用することは著作権法上問題ないか
  • 問題1.「著作権法上問題ないか（著作権侵害にならないか）」と問題2.「契約（利用規約）違反とならないか」の2つがある
  • 「著作権法上問題ないか（著作権侵害にならないか）」
  •  日本著作権法においては、AIソフトウェアの生成に必要な著作物の利用行為（データの複製や翻案）については、原則として著作権者の承諾を行わなくても可能であるという権利制限規定が存在する。この条文は世界的に見るとかなり特殊
  • 日本著作権法が適用されるケース
    • 作業者、サーバが日本 → ◎「日本著作権法が適用」
    • 作業者が日本、サーバが外国 → ？「結論ははっきりしておらず日本著作権法が適用されないリスクがある」
    • 学習対象の著作物が外国企業、外国人の所有物、著作物の利用者が外国人等の状況だが、著作物の利用行為が日本国内 → ◎「日本著作権法が適用」
  • ただし、「当該著作物の種類及び用途並びに当該利用の態様に照らし著作権者の利益を不当に害することとなる場合」には学習用と出会っても、無制限に利用できるわけではない
    • どのような場合に、著作権者の利益を不当に害すると判断されるか。愛知靖之「AI生成物・機械学習と著作権法」によれば、「将来における著作物の潜在的販路を阻害するかどうかで判断する」とある
    • しかし、この記事の著者は、上記の考え方に懐疑的
  • 「私が描いたイラストをAI学習に使うのは禁止にします」と表明することで、実際にイラストが学習に利用されることを禁止できるのか
    • 著作権法の条文等を、契約により無効化することを「オーバーライド」と呼ぶ
    • 一方で、経産省の「新たな知財制度上の課題に関する研究会報告書」によれば、著作権法30条の4をオーバーライドするような契約は、「その範囲において、公序良俗に反し、無効とされる可能性が相当程度あると考えられる」という記載がある
  • どのような場合に「契約が成立した」といえるのか
    • そもそも、著作権者が一方的に「私が描いたイラストをAI学習に使うのは禁止にします」と表明するだけでは「契約」が成立していないと考えられる
    • 「契約」が成立するためには契約当事者双方の意思が合致することが必要とされているため
  • まとめ
    • 「私が描いたイラストをAI学習に使うのは禁止にします」と表明したとしても、そもそもそのような表明は著作権法30条の4に違反して無効の可能性がある
    • 一方的な表明が契約として成立することはないため、結論的にはそのような表明は少なくとも法律的には意味がない
• 4 第3　論点2「画像生成AIにより自動生成された画像に著作権が発生するか」
  •  画像自動生成AIを利用して画像を生成した場合、当該画像に著作権が発生するか。
    • 日本を含むほとんどの国の著作権法の下では、著作権が発生するのは人間の創作物に限られる。AIにより「完全自律的に作成」されたコンテンツには著作権が発生しない
    • 人間がAIを道具として利用したにすぎないのか、AIが完全自律的に生成したと言えるのかどうかがポイントとなる
    • 乱暴に言い切った場合
      • 人間がAIの利用に際して具体的かつ詳細な指示をしていれば → 著作権が発生する
        • 詳細かつ長い呪文を唱えて画像を生成した場合には「創作的寄与」があり、当該画像について著作権が発生する可能性が高くなる
        • 本記事の著者は「AIにより自動生成される複数の生成物から、人間が好みのものを選択する行為」についても「創作的寄与」に該当する可能性は十分にある」としている
      • 人間が簡単な指示しかしていなければ → 著作権が発生しない
        • 詳細な指示、複数制作物からの選択が人間により行われる場合は著作権が発生することを考えると、著作権が発生しないケースは少数かもしれない
        • なお、人間の創作的寄与がない商標でも商標出願はできますし、登録を受けることもできると思われる
      • 自動生成された画像に著作権が発生する場合、誰が著作権を有するのか
        • 画像生成AIソフトウェアの利用規約で「このソフトウェアで作成された画像には著作権が発生します」とか「このソフトウェアで作成された画像の著作者はサービス提供者です」と記載されていても無意味
        • ただし、「ユーザの下で発生した著作権がサービス提供者に無償で移転する」という建て付けは可能
    • 5 第4　論点3「学習に用いられた画像と同一の画像が『偶然』自動生成された場合、著作権侵害に該当するか」
    • そもそも著作権侵害に該当するのか
      • 著作権侵害の成立には、1.類似性、2.依拠性の2つが必要
        • 1.類似性：当該著作物が既存著作物と同一・類似であること
          • 「作風」「スタイル」レベルでしか類似していない場合、には類似性を満たさず、著作権侵害には該当しない
        • 2.依拠性：他人の著作物に接しそれを自己の作品の中に用いること
          • ある創作物がたまたま他人の著作物に似ていても、当該他人の著作物に依拠することなく独自に創作されたものであれば非侵害
      • 著作権侵害に該当する場合に誰が責任を負うのか
        • 仮に類似性、依拠性が肯定されるような場合（著作権侵害に該当する場合）には、誰がどのような責任を負うか
      • （1）　ユーザ
        • ユーザが画像生成指示を行って、当該指示により既存画像と同一・類似の著作物が生成された場合には、当該ユーザ自身が既存著作物の「複製」行為を行っていることになる
        • 私的領域内であれば適法だが、販売、配信した場合には著作権侵害
      • （2）　ツール提供者
        • 著作権侵害における間接侵害の判断
          • 判断基準は「『間接侵害』等に関する考え方の整理」（平成24年1月12日・文化審議会著作権分科会司法救済ワーキングチーム）が整理した第2類型と類似していると考えられる
          • 具体的には「侵害発生の実質的危険性を有する物品」という客観的要件、「侵害発生を知り、又は知るべきでありながら、侵害発生防止のための合理的措置を採ることなく」という主観的要件から、この判断基準は構成される
        • 学習用データセットの生成・提供行為を行った場合
          • 著作権侵害につながる危険性は相当に低い
        • 画像自動生成AIソフトウェアの生成・提供した場合
          • 十分な量の元データからなる画像自動生成ソフトウェアの場合
            • 必ずしも既存著作物と同一・類似の著作物が生成されるとは限らない
            • 仮にユーザの行為が著作権侵害に該当する場合でも、そのようなソフトウェアの生成・提供を行った者には法的責任はないと考えられる
          • 「当該学習済みモデルを利用すると、既存著作物と同一・類似の著作物が非常に高い確率で生成される学習済みモデル」の場合
            • 既存作品と同一・類似の作品を自動生成する能力が非常に高く、著作権侵害をもたらす危険性が高く、前述の間接侵害の判断基準における「侵害発生の実質的危険性を有する物品」という客観的要件を満たす
            • 「侵害発生を知り、又は知るべきでありながら、侵害発生防止のための合理的措置を採ることなく」を満たす場合には法的責任を問われる
          • 画像自動生成AIソフトウェア生成ツールを提供した場合
            • 「侵害発生の実質的危険性を有する物品」という客観的要件を満たさないため、法的責任を問われない

資料

• Midjourney、Stable Diffusion、mimicなどの画像自動生成AIと著作権 | STORIA法律事務所
  • https://storialaw.jp/blog/8820

2022/07/18の週次進捗（サービス開発）

実施したこと

• ミニマム機能のアプリ開発に着手。来週7/25（月）までに機能実装の予定
• Lambda上のNode.js環境にデプロイするためのスクリプトを作成
•  エラー対応
  • Lambda関数を新たに作成し、今回のテストアプリを乗せたところ「ロググループが存在しません」というエラーが発生するようになった
  • こちらの対処は、ひとまず後回し

開発したこと

• 外部へのRESTアクセス
  • axiosモジュールを使用し、まずはGETのみ
  • 続いて、GoogleAPI側で用意している自作のAPIをPOSTで呼び出しデータを渡す処理を実装する

学習したこと

• 新たに学習した個所は無し

所管

• デプロイ、単体テストの類は早めに作っておき、開発を加速させたい

2022/06/27の週次進捗（サービス開発）

実施したこと

• 積み残し課題だったLambdaからS3へのアクセス失敗が解消
• AWS各サービスを利用する際のIAM周りの設定方法をある程度把握（でも、今回のAPIのように例外ケースが一杯ありそう）

開発したこと

• 学習のみで、今週は実装機能なし

学習したこと

• S3へのアクセス権限
  
  • listBucketsのAPIをたたくときに必要なIAMのAction権限は"s3:ListBucket"と"s3:ListAllMyBuckets"の2つ。この2つを設定してあげればよい
  • s3:ListBucketだけではダメというのがハマるポイント
  • 特定のAPIをたたくのにどのAction権限が必要なのか、について調べる方法はないのかもしれない。List*等で全開放してから絞っていくしかないのかも……
  • 結果的には、今回のケースではS3バケットポリシー側を修正する必要はなかった
  • 資料1.のblogでまさに知りたいことを、ずばり記述されていた。ありがたい！
• 資料
  • 資料1.IAM Policyの"Action"に指定できる権限の一覧はどこにあるのか - BioErrorLog Tech Blog

    www.bioerrorlog.work

    •  
  • 資料2,Actions, resources, and condition keys for AWS services - Service Authorization Reference 

    docs.aws.amazon.com

    • 公式情報。Actionに指定できる権限の一覧
  • 資料3.Amazon S3 API Reference - Amazon Simple Storage Service 
    

    docs.aws.amazon.com

    
    
    • 公式のS3 APIリファレンス
  • 資料4.aws s3のパブリックアクセスについてまとめる - Qiita
    

    qiita.com

    
    
    • 「基本的にパブリックアクセスを全部offにしていてもiamで許可しているユーザーは保存できる」とのこと。なるほど
    • S3のパブリックアクセスについては、どこかのタイミングできちんと学習したい（仕掛中のアプリでは不要な知識なので後回し

所管

トラブル対応について

• AWSの知識不足から解決まで時間がかかったが、良い学習になった。開発を加速していきたい
• Webのあちこちに情報が掲載されているのはAWSの強みだと実感