AIプログラミングとは｜著作権・OSSライセンス・セキュリティの注意点と安全な使い方

お役立ち記事

Share

Check!

  • AIプログラミングの2つの意味と、従来の開発との違いがわかる
  • 生成コードの著作権の考え方と、コピーレフト型OSSライセンスが混入するリスクがわかる
  • 入力から記録までの安全な業務フローと、ルールを定着させる方法がわかる
  • 非エンジニアでも「市民開発」でExcelマクロや業務ツールをAIに書かせる流れが広がっている

「AIにコードを書かせると開発は速くなるが、そのまま製品に入れて大丈夫なのか」「生成されたコードにオープンソースのライセンスが混ざっていたら、誰が責任を負うのか」と感じていませんか。AIプログラミングという言葉には、AIの支援を受けてコードを書く開発手法と、AIそのものを作るためのプログラミングという2つの意味があります。この記事は前者、つまり業務でコード生成AIを使う場面を中心に扱います。コード生成AIは、補完・関数生成・テストコード作成・既存コードの説明など、開発の多くの工程で時間を短縮できる一方で、生成コードの著作権の考え方、OSSライセンスの混入、脆弱性の見落とし、外部委託契約での取り決めといった、従来の開発では意識されにくかった論点を生みます。競合の解説記事は活用事例や学習方法の紹介が中心ですが、本記事では、特に実務で見落とされやすい「コピーレフト型ライセンスが意図せず混入するリスク」を軸に、開発責任者とエンジニアが社内で決めておくべきルールと確認フローを整理します。

AIプログラミングの悩みから読むべき解説を診断

Q1. AIプログラミングで一番気になるのは？

おすすめ記事

目次

開く

閉じる
  1. AIプログラミング、次の一歩は正しい使い方の教育｜エンジニア向けeラーニングの比較
  2. AIプログラミングとは｜一般的なプログラミングとの違い
  3. 著作権法上の保護対象であることの意味
  4. OSSライセンス混入リスクとAIコード生成
  5. 導入でよくある失敗パターン4つ
  6. 安全に活用するための業務フロー
  7. 効果をどう確認するか
  8. よくある質問(FAQ)
  9. まとめ
  10. 参考文献

AIプログラミング、次の一歩は正しい使い方の教育｜エンジニア向けeラーニングの比較

AIプログラミングのリスクの多くは、ツールの性能ではなく、使う人がライセンスやセキュリティの基本を知っているかどうかで決まります。コード生成AIは、利用者が指示すれば数秒でそれらしいコードを返しますが、そのコードがどのライセンスのコードと似ているか、どこに脆弱性があるかまでは教えてくれません。まず押さえておきたいのが、OSSライセンスの大きな2つの系統の違いです。

系統 代表的なライセンス 一般的な主な義務 AI生成コードに混入した場合の影響
パーミッシブ型 MIT License、Apache License 2.0、BSDライセンス 著作権表示とライセンス文の保持が中心。Apache License 2.0は変更の明示や特許に関する条項もある 表示義務を落とすとライセンス違反になり得るが、ソースコード全体の公開までは通常求められない
コピーレフト型 GPL、AGPL(弱いコピーレフトとしてLGPL、MPLなど) 派生物を配布する際に、同じライセンスでのソースコード提供が求められる。AGPLはネットワーク経由の提供も対象になり得る 自社製品のソースコード公開を求められる可能性があり、事業への影響が大きい

この表の違いを、開発に関わる全員が同じ水準で理解しているチームは多くありません。ベテランのエンジニアは経験的に知っていても、新しく加わったメンバーや、業務改善のために簡単なスクリプトを書き始めた非エンジニア部門の担当者は、生成されたコードの出どころを気にせずに使ってしまいがちです。AIプログラミングを組織で安全に使うには、ツールの導入と同時に、ライセンス・著作権・セキュリティの基礎を学ぶ場を用意することが次の一歩になります。

そのための手段として現実的なのが、エンジニア向けのeラーニングです。集合研修と違い、メンバーが自分のペースで学べ、受講状況を管理者が確認できます。エンジニア向けeラーニングの比較・おすすめ記事に掲載されているサービスから、AIプログラミングの教育と相性のよいものを、強みと確認しておきたい点で整理すると次のとおりです(内容は比較記事の掲載情報をもとにしています。最新の情報は各サービスの公式情報で確認してください)。

サービス名(提供会社) 強み 確認しておきたい点
Aidemy Business(株式会社アイデミー) 230以上のコンテンツで、初心者から実務経験者までDXやAIのビジネス活用を学べる。専任のカスタマーサクセスがカリキュラム設計を支援 DX学習やAI技術以外の教材は自社で作成する必要がある
プロシーズ(株式会社プロシーズ) 資格対策やビジネス講座に加え、研修のライブ配信に対応。自社で教材を作りたい企業にも向く 別途LearningWareの利用料が必要になる
Schoo for Business(株式会社Schoo) 7,000本以上の動画が見放題で、スマホからも視聴できる 研修のような基礎的な動画が多く、内容が浅いと感じる可能性がある

AIの活用法そのものを体系的に学ばせたいならAIやDXに特化した教材、自社のAI利用ルールやライセンス確認手順を教材化して配信したいなら自社教材を作りやすいサービス、というように、何を教えたいかで向くサービスが変わります。社内ルールの教材化は、既製の講座にはない自社固有の内容を届けられる点で特に有効です。

AIコード生成を安全に使う教育をするなら

エンジニア向けeラーニングを比較する →

AIプログラミングとは｜一般的なプログラミングとの違い

業務でいうAIプログラミングとは、コード生成AIの提案を受けながらプログラムを書き、人が確認・修正して仕上げる開発手法です。AIが全部を書くわけではなく、最終的な品質と責任は人と組織に残ります。

2つの意味を区別する

検索すると、AIプログラミングの解説には2種類が混在しています。1つは、機械学習モデルを作るためにPythonなどで書くプログラミング、つまり「AIを作るプログラミング」です。もう1つは、コード生成AIに指示を出してコードを書いてもらう「AIを使うプログラミング」です。前者では数学や統計、データの前処理の知識が中心になり、後者ではAIへの指示の出し方と、生成物を検証する力が中心になります。業務の現場で急速に広がっているのは後者で、エンジニア以外の職種でも、表計算の集計や定型作業の自動化のために使い始める例が増えています。本記事で扱う著作権やライセンスの論点も、主に後者で生じるものです。

AIを作るプログラミングでできることと使われる言語

「AIを作る」意味でのAIプログラミングは、ルールを人が一つずつ書く従来の方法と違い、データからパターンを学習させたモデルをシステムに組み込む点に特徴があります。業務での主な用途と、よく使われる言語・道具を整理すると次のとおりです。

項目 主な内容
できること 画像認識(外観検査、書類の読み取り)、異常検知(設備の故障予兆、不正取引の検出)、予測(需要や売上の予測)、自然言語処理(問い合わせの分類、文章の要約)
よく使われる言語 機械学習のライブラリが充実したPythonが中心。統計解析ではR、処理速度が求められる部分ではC++なども使われる
主な道具 TensorFlowやPyTorchなどの機械学習フレームワーク、ブラウザ上でPythonを実行できる開発環境
求められる知識 プログラミングの基礎に加え、統計や線形代数、データの前処理、モデルの評価方法

AIを作る側の開発でも、コードを書く作業そのものにコード生成AIを使う場面が増えています。その場合は、以降で解説する著作権・ライセンス・セキュリティの論点がそのまま当てはまります。

従来の開発との違い

観点 従来のプログラミング AIプログラミング
コードの出どころ 自分で書いたコードか、出典のわかるライブラリやサンプル AIの出力。学習元のコードとの関係は利用者から見えにくい
書く速さ 書き手のスキルと経験に比例する 定型的なコードは大幅に速くなる。一方で確認の手間が増える
品質のばらつき 書き手ごとの癖として現れる 指示の出し方で出力が変わる。もっともらしい誤りが混じる
情報の扱い コードは社内の環境にとどまる 入力したコードや指示が外部サービスに送信される場合がある

この比較からわかるのは、AIプログラミングでは「書く」工程が短くなる代わりに、「確かめる」工程の重要性が増すということです。コードの出どころが見えにくくなるため、ライセンスの確認は書き手の記憶ではなく仕組みで担保する必要があります。また、入力したコードが外部サービスに送られる可能性があるため、何を入力してよいかというルールも欠かせません。総務省「令和7年版 情報通信白書」によると、日本で生成AIの活用方針(積極的に活用する方針、または領域を限定して利用する方針)を定めている企業の比率は、2024年度調査で49.7%と、2023年度調査の42.7%から増加しています。活用方針を定める企業が増えるほど、開発部門でも具体的な使い方のルールが求められるようになります。

AIプログラミングが得意な作業と苦手な作業

コード生成AIが得意なのは、よく知られた書き方で済む作業です。データの変換処理、入力フォームの項目チェック、単体テストの雛形、既存コードへのコメント追加、エラーメッセージの意味の説明などは、短時間で実用的な出力が得られやすい領域です。反対に、自社固有の業務ルールを反映した処理、複数のシステムにまたがる設計判断、性能や安全性に厳しい要件がある処理は、AIの出力をそのまま使える場面が少なくなります。AIは自社の業務や既存システムの制約を知らないため、一般論として正しいコードを返しても、自社の文脈では誤りになることがあるからです。得意な作業から使い始め、苦手な作業では「たたき台」として扱うと割り切るのが、導入初期の現実的な進め方です。

プログラムは著作権法で保護される著作物の一つであり、AIが生成したコードでも、既存のコードと似ていれば権利侵害が問題になり得ます。AIプログラミングの著作権の論点は、「生成したコードに自社の権利が発生するか」と「生成したコードが他人の権利を侵害していないか」の2つに分けると整理しやすくなります。

生成したコードに権利が発生するか

文化庁の文化審議会著作権分科会法制度小委員会がまとめた「AIと著作権に関する考え方について」では、AIが生成したものが著作物に当たるかどうかは、人がどの程度創作的に関与したか(創作的寄与)によって個別に判断されるという考え方が示されています。簡単な指示だけでAIが自律的に生成したものは、一般的に著作物とは認められにくいとされています。一方、人がAIの出力を選択・修正・組み合わせて仕上げた場合には、その人の創作的な表現が認められる部分に著作権が生じ得ます。業務の観点で言えば、生成コードを人がレビューし、設計に合わせて手を入れる工程は、品質のためだけでなく、成果物の権利関係を明確にする意味も持ちます。

他人の権利を侵害していないか

同じ「考え方」では、AIを利用して生成したものが既存の著作物の権利を侵害するかどうかは、通常の著作権侵害と同様に、既存の著作物との「類似性」と、既存の著作物に基づいて作られたかという「依拠性」の両方で判断されるとされています。コード生成AIの利用者は学習データの中身を知らないことが多いため、依拠性の判断は単純ではありません。ただ、生成コードが特定の公開コードと表現レベルでほぼ一致している場合には、利用者の認識にかかわらず問題になる可能性があると考えておくのが安全です。

なお、プログラムの著作権で保護されるのは具体的な表現であり、アルゴリズムやアイデア、プログラム言語そのものは保護の対象外とされています。ソートや日付計算のように誰が書いても似た形になる短いコードは、表現の選択の幅が狭く、著作物性が認められにくいとされます。問題になりやすいのは、まとまった量の特徴的なコードが丸ごと再現されたケースです。

利用規約で確認しておくこと

著作権法の考え方とは別に、コード生成AIの利用規約で、生成物の権利の扱い、入力データの学習への利用有無、第三者から権利侵害を主張された場合の取り扱いがどう定められているかを確認しておく必要があります。法人向けのプランでは、入力データを学習に使わない設定や、既存の公開コードと一致する出力をブロック・表示する機能が用意されている場合があります。規約や機能は改定されることがあるため、導入時だけでなく定期的に確認し、確認した日付と内容を社内で記録しておくと、後から経緯を説明しやすくなります。

本記事は一般的な情報提供を目的としたもので、法的助言ではありません。個別の案件で権利関係の判断が必要な場合は、弁護士など専門家に相談してください。

OSSライセンス混入リスクとAIコード生成

AIコード生成で最も気づきにくいリスクが、コピーレフト型ライセンスのコードが断片的に混入し、配布後にソースコード公開の義務が問題になるケースです。著作権の侵害とは別に、OSSを使う以上はライセンス条件を守る必要があり、生成コードもその例外ではありません。

なぜ混入が起きるのか

コード生成AIは、公開リポジトリのコードを含む大量のデータから学習しているとされています。公開コードの中には、GPLやAGPLのようなコピーレフト型ライセンスのプロジェクトも多く含まれます。通常の利用では、AIは学習したパターンを組み合わせて新しいコードを出力しますが、よく知られた関数や特徴的な実装については、元のコードに近い形で出力されることがあります。そのとき、元のコードに付いていたライセンス表示や著作権表示は出力に含まれないため、利用者は出どころを知らないまま自社のコードに取り込んでしまいます。

影響の大きさは「配布するかどうか」で変わる

GPLの義務の多くは、ソフトウェアを第三者に配布するときに生じるとされています。そのため、社内だけで使うツールに混入した場合と、顧客に納品するシステムや販売するアプリに混入した場合とでは、影響の大きさがまったく違います。注意したいのはAGPLで、ネットワーク経由でサービスとして提供する場合にもソースコードの提供が求められ得るため、SaaSやWebサービスを提供する企業では特に慎重な確認が必要です。自社の開発対象が「社内利用」「納品・販売」「ネットワーク提供」のどれに当たるかを把握しておくことが、確認の厳しさを決める出発点になります。

開発対象 ライセンス上の影響の目安 確認の厳しさ
社内だけで使う業務ツール 配布を伴わないため、コピーレフトの義務が問題になる場面は比較的少ない レビュー時の目視確認を基本に、重要なツールは自動スキャン
顧客への納品物・販売するソフトウェア 配布に当たるため、GPL系の混入はソースコード公開や契約違反の問題になり得る 自動スキャンを必須にし、検出時は法務と協議
ネットワーク経由で提供するサービス AGPLの混入はソースコード提供の問題になり得る 自動スキャンに加え、AGPLを明示的に禁止する社内ルール

実務でとれる対策

対策は大きく3つあります。1つ目は、コード生成AIの側で公開コードとの一致を検出・抑止する機能を有効にすることです。2つ目は、ソフトウェア構成分析(SCA)やコードスニペットの一致を調べるスキャンツールを、リリース前の工程に組み込むことです。依存ライブラリの管理だけでなく、コードの断片レベルで既知のOSSと一致していないかを調べられるツールを選ぶと、AI生成コードの確認に向きます。3つ目は、使用しているOSSとライセンスを一覧化したソフトウェア部品表(SBOM)を整備し、何がどこに入っているかを後から追えるようにすることです。

ツールを入れても、検出結果を読んで判断するのは人です。スキャンでGPLのコードとの一致が見つかったとき、書き直すのか、そのライセンス条件に従うのか、影響が小さいとして許容するのかを決めるには、ライセンスの基礎知識が要ります。ここが、先に触れた教育の必要性につながります。

導入でよくある失敗パターン4つ

AIプログラミングの失敗は、ツールの問題よりも、確認の手順と知識の共有が追いつかないことから起きます。導入初期によく見られる4つのパターンを、改善後の状態と並べて整理します。

失敗パターン Before(よくある状態) After(改善後の状態)
1. 動いたコードをそのまま本番へ テストで動いたことだけを確認して反映し、後から入力値検証の漏れが見つかる AI生成コードも通常と同じコードレビューとセキュリティテストを必須にする
2. ライセンスを誰も確認していない 生成コードの出どころを確認せず納品し、顧客の監査でOSSとの一致を指摘される リリース前のスキャンを工程に組み込み、検出時の判断基準を決めておく
3. 入力してはいけない情報の線引きがない 顧客データや認証情報を含むコードをそのままAIに貼り付けてしまう 入力禁止情報を具体例付きで定め、法人向けの設定で学習利用を止める
4. ルールを作っただけで教育していない ガイドラインは社内ポータルにあるが読まれず、新メンバーほど自己流で使う ルールを教材化して受講を必須にし、受講状況と理解度を定期的に確認する

4つのうち、見落とされやすいのが4番目です。多くの企業は、AIの利用ルールを文書として作成するところまでは進めますが、それを全員が理解している状態をつくるところで止まっています。ルールの文書は、配布しただけでは読まれません。特に、プロジェクト単位で外部のエンジニアや新しいメンバーが入れ替わる開発組織では、入ったタイミングで同じ内容を確実に学べる仕組みがないと、知識の差がそのままリスクの差になります。1から3の失敗も、根本をたどれば「知らなかった」「気づけなかった」ことが原因であることが多く、教育の仕組みは他の3つの対策を機能させる土台といえます。

ライセンスの判断基準、入力禁止情報の具体例、レビューで見るべき観点といった自社ルールを短い教材にまとめ、eラーニングで配信して受講と確認テストを必須にすれば、「読んだかどうかわからないガイドライン」を「全員が一度は学んだルール」に変えられます。受講履歴が残るため、顧客からAI利用の管理体制を問われた際にも、教育の実施状況を示す材料になります。

ライセンスリスクを社内で教育する

エンジニア向けeラーニングを比較する →

安全に活用するための業務フロー

AIプログラミングを安全に使うには、「入力」「生成」「確認」「記録」の4段階それぞれに、誰が何をするかを決めておくことが基本です。経済産業省と総務省が取りまとめた「AI事業者ガイドライン」では、AIを業務で利用する事業者(AI利用者)にも、安全性やセキュリティ、透明性、アカウンタビリティなどへの配慮が求められています。開発現場のルールは、こうした全体の方針を具体的な作業に落とし込んだものと位置づけると、社内の説明がしやすくなります。

段階 やること 担当の例
1. 入力 承認済みのツールだけを使い、顧客データ・認証情報・未公開の独自ロジックを入力しない 開発者本人(ツールの承認は情報システム部門)
2. 生成 公開コードとの一致を抑止する設定を有効にし、生成コードであることがわかるようにコミットやレビューに記す 開発者本人
3. 確認 コードレビュー、セキュリティテスト、ライセンススキャンを実施し、検出時は判断基準に沿って対応 レビュー担当者、必要に応じて法務
4. 記録 使用ツールと設定、スキャン結果、OSSの一覧(SBOM)を残す 開発責任者

セキュリティ確認で見るべき点

AIが生成したコードは、学習データに含まれる古い書き方や、脆弱性のある書き方を再現することがあります。特に注意したいのは、入力値の検証が不十分なコード、SQLを文字列連結で組み立てるコード、認証やアクセス制御の処理が省略されたコード、秘密情報をソースコードに直接書き込むコードです。ウェブアプリケーションであれば、IPA(独立行政法人情報処理推進機構)の「安全なウェブサイトの作り方」で解説されているSQLインジェクションやクロスサイト・スクリプティングなどの代表的な脆弱性と対策を、レビューの観点表として使うと確認漏れを減らせます。生成コードだから特別なテストをするのではなく、人が書いたコードと同じ基準を必ず通すことが基本です。

外部委託先との取り決め

開発を外部に委託する場合、委託先がAIプログラミングを使うかどうかは、発注側から見えにくい部分です。契約や発注時の取り決めで、AI利用の可否と利用する場合の条件、生成コードの権利の帰属、OSSライセンスの確認責任、納品時に提出するOSS一覧やスキャン結果の有無を明確にしておくと、後のトラブルを避けやすくなります。委託先に自社と同じルールを求める場合は、ルールの内容を委託先の担当者にも共有し、理解してもらう機会を設けることが大切です。

小さく始めて範囲を広げる

最初から全プロジェクトに適用するより、社内向けの業務ツールや、テストコードの作成といった影響範囲の小さい用途から始め、フローが回ることを確かめてから、顧客向けの製品開発に広げる方が、リスクを抑えながら効果を確かめられます。プログラミング知識がない部門の業務改善では、コードを生成するAIより、画面操作でアプリを作れるノーコードツールの方が、レビューの負担が少なく適している場合もあります。

効果をどう確認するか

AIプログラミングの効果は、書く速さだけでなく、手戻りやレビューの負担、ルールの定着度まで含めて測る必要があります。書く時間が短くなっても、レビューや修正の時間が増えれば、全体としての効果は小さくなるからです。

観点 指標の例 見方
開発の速さ タスクの着手から完了までの時間、プルリクエストの作成数 導入前の同種のタスクと比べる
品質 レビューでの指摘件数、リリース後の不具合件数、脆弱性の検出件数 速さが上がっても品質が落ちていないかを確認する
ライセンス管理 スキャンでの一致検出件数、検出から対応完了までの日数 検出件数がゼロでも、スキャンが実施されているかを確認する
ルールの定着 ルール教材の受講率、確認テストの正答率、入力禁止情報の違反件数 新メンバーの受講が漏れていないかを定期的に見る

導入から数か月は、速さの指標が改善する一方で、レビューの指摘件数が一時的に増えることがよくあります。これは確認の仕組みが機能している証拠でもあるため、すぐに悪い結果と判断する必要はありません。指摘の内容を分類し、同じ種類の指摘が繰り返されるようであれば、それはチーム全体の知識の穴を示しています。例えば、入力値の検証漏れが繰り返し指摘されるならセキュリティの基礎、ライセンス表示の欠落が続くならOSSライセンスの基礎を、教材として補強すると効果的です。

このように、効果測定の結果を教育の内容に戻す循環をつくると、AIプログラミングのスキルは個人の経験に頼らずチームに定着していきます。受講状況や理解度を記録できるeラーニングは、この循環の「教育」の部分を担う手段として使いやすいものです。IT研修向けの教材を幅広く探したい場合は、IT研修向けeラーニングシステムの比較も参考になります。

開発チームのスキルを定着させる

エンジニア向けeラーニングを比較する →

よくある質問(FAQ)

Q. AIプログラミングとは何ですか？

A. 業務の文脈では、コード生成AIの提案を受けながらプログラムを書き、人が確認・修正して仕上げる開発手法を指すことが多いです。AIそのものを作るためのプログラミングを指す場合もあるため、どちらの意味で使われているかを区別すると理解しやすくなります。

Q. AIが生成したコードの著作権は誰にありますか？

A. 文化庁の考え方では、AI生成物が著作物に当たるかは、人の創作的な関与の程度によって個別に判断されるとされています。簡単な指示だけで生成したものは著作物と認められにくい一方、人が選択・修正して仕上げた部分には権利が生じ得ます。利用するサービスの規約もあわせて確認してください。

Q. 生成コードにOSSのコードが混ざることはありますか？

A. 可能性はあります。よく知られた実装では公開コードに近い形で出力されることがあり、元のライセンス表示は含まれません。特にGPLやAGPLのようなコピーレフト型が混入すると、配布やサービス提供の形態によってはソースコード公開の問題になり得るため、リリース前のスキャンが有効です。

Q. AIが生成したコードはセキュリティ面で安全ですか？

A. 動作していても、入力値の検証漏れや古い書き方などの脆弱性が含まれる場合があります。人が書いたコードと同じ基準でコードレビューとセキュリティテストを行うことが基本です。IPAの「安全なウェブサイトの作り方」などをレビュー観点として使うと確認漏れを減らせます。

Q. 外部委託先がAIプログラミングを使う場合は何を決めておくべきですか？

A. AI利用の可否と条件、生成コードの権利の帰属、OSSライセンスの確認責任、納品時に提出するOSS一覧やスキャン結果の有無を、契約や発注時の取り決めで明確にしておくことが一般的な対応です。自社ルールを委託先にも共有しておくと、認識のずれを防げます。

Q. 社内でAIプログラミングのルールを定着させるにはどうすればよいですか？

A. ルールを文書で配布するだけでなく、ライセンスの判断基準や入力禁止情報の具体例を短い教材にまとめ、受講と確認テストを必須にする方法が有効です。eラーニングを使えば受講状況を記録でき、新しく加わったメンバーにも同じ内容を確実に届けられます。

まとめ

AIプログラミングは、コードを書く時間を短くする一方で、生成コードの出どころが見えにくくなるという新しい課題を生みます。安全に使うために、まず取り組みたいのは次の4つです。

  1. 入力してよい情報と使ってよいツールを決め、法人向けの設定で学習利用や公開コードとの一致を抑止する
  2. AI生成コードも人が書いたコードと同じレビューとセキュリティテストを通す
  3. 開発対象が社内利用か、納品・販売か、ネットワーク提供かに応じて、ライセンススキャンの厳しさを決める
  4. ルールを教材化してeラーニングなどで全員に届け、受講状況と理解度を定期的に確認する

ツールの性能は日々向上しますが、ライセンスやセキュリティを判断するのは最後まで人です。使う人の知識をそろえることが、AIプログラミングの効果を安全に引き出す近道になります。なお、本記事は一般的な情報提供を目的としたもので、法的助言ではありません。ライセンスや権利関係の個別の判断は、専門家に相談してください。

参考文献

この記事に興味を持った方におすすめ

あなたへのおすすめ記事

同じカテゴリの記事を探す

同じタグの記事を探す

同じタグの記事はありません

掲載希望の方はこちら
top