日時：令和6年2月29日（木） 15:00～17:00 場所：日比谷スカイカンファレンス 11階（RoomB） （オンライン併用） 配布資料 資料1 「AIと著作権に関する考え方について（素案）」に関するパブリックコメントの結果について（2.5MB） 資料2-1 AIと著作権に関する考え方について（素案）令和6年2月29日時点版（溶け込み）（1.5B） 資料2-2 AIと著作権に関する考え方について（素案）令和6年2月29日時点版（見え消し）（1.5MB） 資料3 令和5年度法制度小委員会の審議の経過等について（案）（239KB） 参考資料1 第23期文化審議会著作権分科会法制度小委員会委員名簿（141KB） 参考資料2 生成AIに関するクリエイターや著作権者等の主な御意見（200KB） 参考資料3 法30条の4と法47条の5の適用例について（第4回法制度小委員会配布資料）（151KB）
1 はじめに 2023年12月20日に文化審議会著作権分科会法制度小委員会（第5回）が開催され、そこで文化庁が「AIと著作権に関する考え方について（素案）」を公表しました（以下「素案」といいます。） 本記事では、素案のうち、まずは「（1） 学習・開発段階」について、私なりに検討をしたいと思います。 なお、2024年1月15日に文化審議会著作権分科会法制度小委員会（第5回）が開催され、そこでさらにバージョンアップされた素案が公表されますので、本記事はそれまでの暫定的な検討ということになります。 ということで、短命な？記事ですが、早めに公開することにも意味があるだろうと思い、公開します。 以下、素案を適宜分割し、引用した上で当該引用部分についてのコメントを記載していきます。また、適宜見出しを付けていきます。 2 素案についての考察 （1） 導入部分 AIと著作権に関する考え方について（素案）
※ 本記事で解説している「考え方」は、R6.3.15に更新されています。更新版の解説は以下のnoteをご参照ください。 2023年12月20日、文化審議会著作権分科会法制度小委員会の資料として、文化庁の「AIと著作権に関する考え方について」の素案が示されました（以下「考え方」と表記します）。 2024年3月の取りまとめが予定されており、内容は変更になる可能性がありますが、速報的に内容を抜粋し、ご紹介いたします。 ※ 速報の性質上、内容を適宜更新する場合がありますので、ご了承ください。 「考え方」の構成生成AIと著作権の検討においては「学習・開発段階」と「生成・利用段階」とを、それぞれ分けて考える必要があります。 「考え方」でも、①学習・開発段階、②生成・利用段階に分けて、それぞれ見解が示されています。また、③生成物の著作物性、④その他の論点についての見解も示されています。 なお、分量の都合
今日、文化庁は生成AIと著作権保護についてのガイドラインとなる素案を提示しました。(2023/12/20時点。その後の状況については追記をお読みください。) 生成AIでなにが合法でどんなとき違法になるべきか、クリエイターや開発者、ビジネス系のひとなどが議論していますが、多くの生成AI周辺にいる人たち全員に関係あるガイドラインがいままさに検討されているわけです。 朝日新聞ではこう報じています。 文化庁は20日、文化審議会著作権分科会の法制度小委員会に、生成AI（人工知能）によるコンテンツの無断学習は、著作権法で著作権者の許諾が不要とされる「非享受目的」にあたらない場合があるとする「AIと著作権に関する考え方」の素案を示した。生成AIが記事や画像データなどを無断で利用する「ただ乗り」（フリーライド）に懸念の声が上がる中、現行法を厳格に解釈し、歯止めをかけたい考えだ。 朝日新聞デジタルより引用
今日は、法務・コンプライアンス・AI倫理担当の古川が担当させていただきます。ABEJAアドベントカレンダー2023の3日目の記事です。これで４回目のアドベントカレンダーです。筆者の経歴などは過去の記事で書きましたので省略します。若干追加するならば、Global Partnership On AI（GPAI）というOECDが運営するAIの適切な利活用に関する取り組みの日本の専門家委員を1月からやっております。GPAIを通じてAI倫理だとか責任あるAIの国際的な様々な取り組みに関与させていただいています。 今年も去年に従って「AI倫理ニュース振り返り2022年」を書こうと思ったのですが、より興味が高いであろう国内外のルールメーキングの状況をお話しします。といっても、EU、US、日本だけですが。 １．EU EUはAI法案が非常に重要です。2021年にAI法案をリリースしています。その後、議会によ
生成AIへのプロンプト入力時に問題となる個人情報保護法の論点をまとめました。 本稿作成時点(2023年9月1日)における見解であり、今後、個情委が公表する内容等によって内容はアップデートする可能性がある点についてご留意ください。 プロンプト入力時における個人情報保護法論点フローチャート 生成AIにプロンプトを入力するにあたり、個人情報保護法（個情法）上問題となり得る点をフローチャートにしてみました。 白色の帰結は、個情法に抵触せずに利用できる可能性が高い場合です。他方でグレーの帰結は、個情法に抵触するか（目的外利用）、本人（プロンプトに含まれる個人情報の主体）からの同意取得が必要になるため、適法に利用するためには一定の困難が生じる可能性がある場合です。以下、①から順番に解説していきます。 ①入力するプロンプトは個人情報か 入力するプロンプトが個人情報にあたらなければ、原則として個情法の問題
文章生成AI 利活用 ガイドライン Version 2.0 令和6年（2024年）4月 東京都デジタルサービス局 2 はじめに このガイドラインは、東京都で初めてとなる文章生成AI の利活用ガイドラインです。 ChatGPTをはじめとする文章生成AIは、都職員の業務 のあり方を大きく変革する可能性を秘めている一方、 様々なリスクも指摘されています。このため、業務での 活用にあたり期待する効果を得るためには、その特性を よく理解し、正しく利用することが重要です。 東京都では、デジタルサービス局に検討プロジェクト チームを設置して、文章生成AIの利活用について議論を 重ね、令和5年８月、検討の成果をガイドライン （Version 1.0）としてまとめ、文章生成AIの全庁利用 を開始しました。 その後、10月に利用状況についてアンケートを行った ところ、活用事例やプロンプト例を求める声が多かった
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog TL;DR:2022にフロントエンド開発で最も考慮すべきユーザー環境は、パフォーマンスでは低スペックのAndroid端末、標準仕様では2年前のSafari、そしてネットワークでは４Gです。それに対してはJSへの過剰依存などが原因で主にパフォーマンスの面でのウェブ全体の対応がよくありません。 こんにちは！LINEフロントエンド開発室のダバロス アランです。この記事のタイトルを見て「釣りタイトルですね〜」と考えている方がいると思いますが今回に限ってはそれを大目に見てください。それはなぜかと言いますと、2021年から2022年にかけて私たちフロントエンドエンジニアが全体的に考え方を改める必要が出るほど大きな変化がありました。 その変
経済産業省は11月22日、システム開発時に使う設計書・仕様書などの「作業生産物」のレビュー工程についてJIS規格を制定したと発表した。仕様書などの見直し方や観点などを規格化し、ソフトウェアの品質向上や開発の効率化を促す。 「JIS X 20246」は、設計書・仕様書の見直し作業を「計画作業」「レビューの立ち上げ」「個々人のレビュー」「要検討項目の共有および分析」「修正作業および報告作業」の順に整理し、実行するべきタスクや手順を規定するもの。システム開発や試験、保守などの場面で作るあらゆる仕様書に適用可能。 レビューの曖昧さをなくすため、「目的」「役割」などのレビューの観点10種、「執筆者確認」「同僚との机上確認」などのレビュー手法9種を定めた。JIS制定により、組織や個人のノウハウに依存することなく一定水準のレビューができるようになり、ソフトウェアなどの制作物の品質向上につながるとしている
Kyashの@konifarです。 エンジニア採用応募者向けに、Kyashの面接のフローや目的などを明記した『採用面接ガイド』を作ってGitHubリポジトリで公開しました。 github.com きっかけ Kyashでは応募者とKyash双方にとってよりよい採用面接を行うべく日々フローを改善しています。 その一環で、2020年8月からAndroid/iOSの技術面接にエンジニア2人が一緒に出席することにしました。2人で面接することで、『事前準備や当日の議事録作成などの負担を減らせる』『同じ質問の重複を防げる』といったメリットがあります。一方で、面接者が2人いると応募者が緊張してしまい正しい見極めができないこともあるのではないかという懸念の声も社内で上がっていました。 私も気になったのでTwitterアンケートで聞いてみたところ、15%くらいの方は緊張して面接内容に支障が出そうと答えていまし
本記事は Go Advent Calendar 2019 11 日目の記事です。 Go はシンプルな言語機能・シンタックスが特徴であり、命名規則にもそのシンプルさが表れています。 本記事では、公式や著名な Go エンジニア、OSS などから見られる Go らしい命名規則を紹介します。 今更なテーマかもしれませんが、意外にも公私共々で命名規則が意識されていないコードを時折見かけるので、自戒も込めて記します。 誤った内容があれば Twitter でご指摘いただければと思います。 パッケージ名簡潔にするEffective Go では、short, concise, evocative なパッケージ名が望ましいとされます。 これはパッケージ名に限らずほとんどあらゆる命名において役立つ指針だと思います。 また、「パッケージ名は一言で何をするかを表すエレベーターピッチだ」という Dave Cheney
◆ NamingConvention https://namingconvention.org/ 紹介 「NamingConvention」は、プログラミング命名規則のガイドラインを作成・収集・維持するオープンソースプロジェクトです。 「C#・Git・Java・Python」が、現在作成進行中です。 Gitの章には、ブランチ名やコミットメッセージ、プルリクのネーミング規定が記載されています。 例えば、ブランチネームだと必須や許可と一緒に例文も記載されています。 プログラミング言語（Java）だと、このようになっています。 推奨のネーミングというより、キャメルケースなど、最低限準拠すべき形式が書かれています。 プログラミング版wikipediaになるような、熱量高いコミュニティが続いて欲しいです。 ◆ NamingConvention https://namingconv
About GitHub Pages GitHub Pages is a static site hosting service that takes HTML, JavaScript files straight from a repository on GitHub, optionally runs the files through a build process, and publishes a website. You can see examples of GitHub Pages sites in the GitHub Pages examples collection. You can host your site on GitHub's github.io domain or your own custom domain. For more inf
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Shopify Polaris
