Google Workspace (Formerly G Suite)のAPIをService Accountで利用する方法

はじめに

Service Accountを使って、Admin APIを呼び出せるのですが少々ハマったので備忘がてらに記事にします。
ちゃんと説明しているページを見つけてしまえば早かったですがそこにたどり着くまで時間がかかりハマってしまいました。
以下に参考になるページのリンクを張っておきましたのでご参考にしていただければと思います。

Service Accountとは

つまるところユーザアカウントに紐づかないアカウントです。
Service Accountに権限を付与することによってService Accountが代理でJobを実行する仕組みです。ユーザ側としてはそのService Accountを利用する権限を持っていればよく、ユーザの権限では実施できないこともService Accountにやってもらうことができます。（Service Account Userとして権限付与は必要です）。
ただし、なぜかGoogle WorkspaceのAdmin APIではユーザ側も結局API利用権限が必要です。

Google WorkspaceでのService Account利用の流れ

1. Developer Consoleでの設定
   1. Google Admin APIの有効化
   2. Service Accountの作成およびKeyの作成
   3. Domain-wide Delegationの有効化
2. Admin Consoleでの設定
   1. Delegationの設定
   2. Delegate先のユーザにAdmin API利用権限の付与

1-1から1-3と2-1のやり方については、すべてここに書いてあります。
Perform Google Workspace Domain-Wide Delegation of Authority

2-2については、Admin Roleの設定で、以下に記載があります。
Create, edit, and delete custom admin roles - Google Workspace Admin Help

コード例

上記ページにPython等でのKeyファイルの読み込み例の記載がありますが、なぜか推奨方法ファイル形式はjsonであるにもかかわらず、p12の場合を例にしています。Jsonの場合は以下のとおりであり、ほとんど変わりません。

#    credentials = ServiceAccountCredentials.from_p12_keyfile(
#       SERVICE_ACCOUNT_EMAIL,
#        SERVICE_ACCOUNT_PKCS12_FILE_PATH,
#       'notasecret',
#       scopes=['https://www.googleapis.com/auth/admin.directory.user'])
credentials = ServiceAccountCredentials.from_json_keyfile_name(filename=filename, scope=scope)

Scopeについて

以下を参考に必要なスコープを設定しましょう。
Directory API: Authorize Requests  |  Google Developers
例えば、Groupsの設定変更をしたいのであれば、以下を指定します。

['https://www.googleapis.com/auth/admin.directory.group']

([]で囲ってあげないとエラーになります。)

最後に

いまいちDelegateの部分が良くわからないので詳しい人教えていただけると幸いです。
Service Account利用者側からすると、Keyファイルさえあればどの任意のユーザで試せちゃうというのはセキュリティ上よろしくない気がしますが、どのように使うのが正解なのでしょうか？
なんにせよこれで入退社の管理タスクはすこしは楽にできます。

California Privacy Rights Act (CCPA 2.0)について

はじめに

CCPA対応も済んでいない企業もいるなかで、CPRAが住民投票により採択されました。罰金額が3倍の$7,500になるなどCCPAより厳しい内容になっています。
本記事では簡単に採択にいたるまでの背景とCCPAとの差を中心にご説明いたします。

CRPA採択の背景

CPRAは、市民による立法プロセスを経て法律として制定されました。CCPAの紹介記事でもご説明したように、カリフォルニアには「市民が法律を作成できる仕組み」があります。CCPAのもととなる法律も元々はこの仕組みで法律化されるところを、カリフォルニア州政府が自ら類似の法律を通すことで市民立法を避けました。市民立法で制定された法律は容易に変更できないという特徴があり、これを避けたかったためです。
しかし、CCPAを提起したグループは、CCPAに満足しておらず（カリフォルニア州政府によって規制が弱められたと考えている）、今回のCPRAの立法に至りました。

タイムライン

CPRAのほとんどの項目は2023年1月まで有効になりません。また、2023年7月に強制化される予定です。
ただし、「知る権利」については、2022年1月以降に収集された個人情報も対象になります。
なお、B-to-Bでビジネスを行っている事業者については、CCPA同様に2023年1月まで猶予されています。

CCPAからの主な変更点

対象企業の変更

CCPAでは主に個人情報を事業に用いて収益を上げていた企業を対象にしていたところを、個人情報を何らかの形で共有するだけでも対象になりました。その一方で、個人情報の件数の制限は緩められ、50,000件→100,000件へ変更となりました。

権利の追加・拡張

以下の新しい権利が追加・拡張されました。

権利名	拡張	説明
個人情報を修正する権利	追加	事業者の持っている情報を修正する権利
プロファイリングや自動化された意思決定に関する権利	追加	GDPRでも規定されている権利。プロファイリングや自動化された意思決定に関してオプトアウトやどのような情報の使われ方がされているか知る権利
センシティブな個人情報を制限する権利	追加	第三者提供の禁止など2次的な目的での利用を制限できる権利
削除する権利	拡張	削除要求を受けた事業者は、その個人情報を提供した第三者へ削除を要求する必要性が追加されました。
データの移行性の権利	拡張	個人情報を他事業者に受け渡し可能な形で提供を受けることのできる権利

監査の義務化

CPRAでは、個人情報の取り扱いに関するリスク評価および情報セキュリティ監査を実施することが求められます。また、リスク評価の結果は定期的にCPPA (California Privacy Protection Agency) に提出する必要があります。（CPPAは、CRPAにより設置される組織）

CPPAの設置

現在CCPAでは、California Office of the Attorney General（OAG）によって施行されていますが、CPRAではCCPAという機関を新たに設置し必要な権限を与えています。GDPRは、各国でPrivacy専門の法的機関によって運営されているが、カリフォルニアにはそのような専門の組織がなく今回設置されることになったと考えられます。

GDPRの原則の取り込み

GDPRで存在する以下の3つの原則が取り込まれました。

• データの最小化原則

必要のある情報だけを収集するようにするという原則です。

• 目的の限定原則

目的外利用の禁止の原則です。初めに開示した利用目的以外の目的で利用する場合は、必ず再度本人に通知する必要があります。

• 保管制限の原則

適切な保管期間を定めそれを超えたら速やかに削除することをもとめる原則です。

業務委託事業者への義務の追加

以下の義務が委託事業者に課されました。

• 再委託の通知義務および同様の要件の再委託契約への盛り込み義務
• 委託事業者がプライバシー権の対応を支援する義務
• 委託事業者へ個人情報を渡す場合に、委託事業者がその他の情報と組み合わせて使わないことを契約に盛り込む義務

センシティブ情報の概念の追加

センシティブな個人情報とは、以下のような情報とされています。

• ソーシャルセキュリティ番号
• 免許証番号
• 銀行口座情報
• 位置情報
• 人種、信仰
• 公開されていないコミュニケーション（メールやテキスト等）
• 生体に関する情報
• 性的嗜好

まとめ

全体的にGDPRに近い内容の個人情報保護に関する法律となっていると思われます。
CCPAの本来の意図をくみ取って対応していた場合はそこまで大きな変更にはならないかもしれません。今後ルールが整備されてきますのでCRPA対象事業者は状況を定期的に確認することをお勧めします。

おまけ（CRPAは容易に変更できない）

悪名高いともいわれる市民による立法プロセス、これは主に以下によって容易に変更できないことによります。
これは、基本的に変更にあたって市民による投票が再度必要となるためです。法律上はカリフォルニア州政府も変更可能ではあるようですが、いかなる変更もその法律本来の意図に沿ったものでないといけないという制約があります。これにより、仮にプライバシーにより配慮する変更を加える場合であっても住民からカリフォルニア州政府が訴えられかねないというリスクがあり、州政府が変更を加えることが難しくなっています。

LISA: A Practical Zero Trust Architecture (簡易的なゼロトラストの実装モデル）

はじめに

本記事では、Zero Trustの一つの実装モデルであるLISA（Location Independent Security Approach）をご紹介します。
COVID-19により多くの企業がリモートワークを強いられていることと思います。このため、Zero Trustモデルが昨今非常に注目されています。しかし、Zero Trustは色々なベンダーが「俺のゼロトラスト」を主張しており、実装イメージがいまいち掴みにくいところがあります。ゼロトラストを実現したGoogle社のBeyondCorpが発表されたものの、重厚長大で実装に向けてスタートしづらい面があります。そのようななか、Netflix社のLISAモデルは既に多くの企業が導入しているようなソリューション群を利用した簡易的なゼロトラストの実装モデルを発表しました。
なお、本記事は以下のUsenixの発表をもとにしています。

USENIX Enigma 2018 - LISA: A Practical Zero Trust Architecture

ゼロトラストとは

Forrester社が提唱し、Zero Trust Securityの考え方が生まれました。Zero Trust Securityでは、Perimeter Security（境界セキュリティ）で信用していた境界内（オフィスネットワークなど）をも信用せず常に検証する形としたところが大きな違いです。

Zero Trustが必要とされるようになってきたのは、大きく以下3点の変化によりPerimter Securityでは情報を守れなくなってきたことによります。

• 攻撃の高度化

攻撃が高度化し、すべての攻撃を防ぐことが難しく侵入されるのが当たり前になってきた。
このため、脅威が内側に入ってくるのが当たり前としてとらえなければならなくなった。
Permiter Securityの考え方は内側は信頼しているので、いったん侵入された脅威に非常に脆弱となっている。

• クラウドの利用の拡大

クラウドの利用が拡大し、重要な情報が、信頼できる「内側」だけでなく、「外側」にも配置されるようになった。利用者はどこからでもアクセスできるようになり、境界の「外側」からもアクセスでき、境界で実施していたセキュリティ対策が意味をなさなくなってきた。

• 多種多様なデバイスの利用の拡大

BYOD（個人所有の端末）が広まったり、IoTデバイスの数も増えてきたため、内側外側という考え方だけでなく、どのようなデバイスであるかも踏まえたうえでアクセス制御が必要になってきた。

簡易なゼロトラスト実装モデルであるLISA

LISAの概要

LISAでは、いかなるリソースもVPNに接続しない限りは利用できないようにすることで、セキュリティを担保します。
以前から、VPN接続時において端末のセキュリティ対策状況のチェックを行っていた企業は多いのでしょうか？LISAでは、リソースにアクセスするすべての端末をVPNに接続させ端末のセキュリティ対策状況をチェックすることにより、Zero Trustの「常に検証する」という考え方を実現します。
発表のなかでは、オフィスのネットワークをカフェのネットワークのように取り扱えといっており、Zero Trustらしいものといえます。

LISAの基本的考え方

LISAで利用される技術

利用されている技術としては、以下3つ程度でありどのような環境でもすでに用いられているものではないでh草加？このため容易に始められるのが特徴といえます。

• スイッチによるポートVLAN
• VPN機器による端末のリスク評価
• Firewall

なお、スイッチによるポートVLANによって、オフィスのネットワークに接続されている端末同士もポートVLANで分離することによって直接通信ができないようにしています。
Firewallによって、端末のリスク評価の結果などを踏まえて接続可能な箇所を制御します。

LISAの実装に向けて

どのようなZero Trustの実装であっても共通していますが、まずどのようなユースケースがあるか情報の流れがあるかを把握することから始まります。また、導入はエンドユーザの体験に大きく影響するので、エンドユーザをZero Trustの実装プロジェクトにどんどん巻き込むことが重要といえます。
LISA利用の場合であっても当然イレギュラー対応が必要なケースも発生してくるでしょう。（VPNが利用できない場合等）そのようなケースは例外として扱い、VPNなしで接続させるものの可能な限りアクセス可能な範囲を絞るというアプローチをとることが発表の中でも言われています。

まとめ

Zero Trustは、昨今のセキュリティ事情を踏まえると、今後「常識」となっていくのではないでしょうか？
Zero Trustといっても実装方式には様々な方法があるので、企業にあった実装方式を選択し実装していくことになることと思います。そのなかでもLISAは導入が容易ですので、検討に値するのではないかと考えます。

セキュリティやIT系の用語の英訳メモ（随時更新予定）

セキュリティやIT周りの用語の英訳を備忘のためにメモ。随時更新していこうかと思います。
この用語はなんて訳すのなどリクエストあれば、コメント欄に記入いただければ気づいたときにUpdateします。

区分	日本語	英訳	補足
ポリシー全般	規定	rules
ポリシー全般	適用対象	scope
ポリシー全般	定義	definitions
ポリシー全般	情報セキュリティ基本方針	Information Security Charter
ポリシー全般	維持	maintain/maintenance
ポリシー全般	概要設計	high-level design
ポリシー全般	更新履歴	change history
ポリシー全般	策定	develop/development
ポリシー全般	情報機器	IT devices
ポリシー全般	役員	executives
ポリシー全般	監督責任	supervisory responsibilities
ポリシー全般	残余リスク	residual risk
ポリシー全般	公的機関	public authority
ポリシー全般	情報開示	information disclosure
ポリシー全般	改ざん	tampering
ポリシー全般	情報閲覧	access to information
ポリシー全般	リスク対応策	risk control
ポリシー全般	記憶媒体	storage media
ポリシー全般	管理責任者	person in charge
ポリシー全般	セキュリティ管理策	security controls
ポリシー全般	是正措置	corrective action
ポリシー全般	保存期間	retention period
ポリシー全般	社外への持ち出し	taken out off-premise	文脈によってはsent external
ポリシー全般	指定の機器	designated device
ポリシー全般	承認	approval
ポリシー全般	部署/部門	department	divisionという言葉はあるが、ネイティブに聞くと英語ではあくまで分けられたものという意味が強い。X department is a division of Y departmentという使い方はできるけど、X division という使い方はあまりしないそう。
ポリシー全般	ノートパソコン	Laptop PC
ポリシー全般	個人所有のパソコン	personal device
ポリシー全般	廃棄	disposal
ポリシー全般	不審な	suspicious
ポリシー全般	代替策	compensating control
ポリシー全般	対象外	not applicable
ポリシー全般	意図しない	unintended/undeliberated
ポリシー全般	意図して	deliberately/	intentionally
ポリシー全般	内部不正	insider threat
ポリシー全般	業務要件	someone's operational requirements
ポリシー全般	会社PC	company-owned computer
ポリシー全般	自社ソフトウェア	proprietary software
インシデント管理	一次対応	Initial Response
インシデント管理	マルウェア感染	malware infection
ネットワークセキュリティ	ネットワーク境界	network perimeter
ネットワークセキュリティ	社内から社外への接続	outbound connection
ネットワークセキュリティ	社外から社内への接続	inbound connection
ネットワークセキュリティ	マルウェア対策	anti-malware
ネットワークセキュリティ	踏み台サーバ	jumpbox server
ネットワークセキュリティ	侵害	compromise
人的セキュリティ	人的セキュリティ	human resources security
人的セキュリティ	異動	transfer
人的セキュリティ	退職	termination
人的セキュリティ	入社	join the company
委託先管理	派遣社員	temporary worker
委託先管理	外部委託先企業/社外委託先	contractor
委託先管理	機密保持契約	non disclosure agreement
委託先管理	再委託	third party vendor
委託先管理	セキュリティチェック	Security assessment
情報管理	情報資産	information asset
情報管理	情報資産管理台帳	information asset inventory
情報管理	分類	classification
情報管理	情報漏洩	data breach
物理セキュリティ	入館証	Access badge
物理セキュリティ	執務場所	office spaces
物理セキュリティ	事業所	office
物理セキュリティ	入室	access
物理セキュリティ	ゲスト	visitors
物理セキュリティ	伴連れ	piggybacking	tailgating という言葉も似たような意味であるが、こちらの場合は先に入ったものが知らないうちに後ろについていく形。一方で、piggybackingは先に入ったものが意図して後ろについてきたものを入れてあげる形。
物理セキュリティ	立ち入り許可	access permit
物理セキュリティ	シール	sticker	sealは封をするためのもの
物理セキュリティ	USBメモリ	USB thumb drive
物理セキュリティ	入館者管理簿	visitor registration book

Python Pandas groupbyは便利

はじめに

データ分析していると、「集計後のデータがある条件にマッチする行だけ抽出したい」、「集計後のデータを集計前の対応する行に追加したい」などと思う場面があると思います。
それって、Pandasのgroupbyを使うと簡単にできます。みなさんご存じかもしれませんが、ちょっと使っていて便利だと思ったので共有したいと思います。

集計後のデータがある条件ににマッチする行だけ抽出したい

言葉で説明するとわかりにくいので実際に以下を例にしてみます。
Labelごとで集計してValueの合計が100より大きい場合、元のデータから対象の行を抽出する。

AのValueの合計は190(>100)、BののValueの合計は190(>100ではない)、CのValueの合計は120(>100)。このため、Label AとLabel Cの行を抽出するという動きです。
これは簡単にDataFrame.groupby.filterを使うことで実現できます。

df_test=pd.DataFrame([['A',50],['A',100],['A',40],['B',80],['B',10],['C',120]],columns=['Label','Value'])

df_test.groupby(by=["Label"]).filter(lambda x: sum(x["Value"])>100)

  Label Value
0 A 50
1 A 100
2 A 40
5 C 120 

filterを知らずにやろうとするといったん集計したデータを作ってjoinさせた上で特定の条件で絞り込む必要があります。

集計後のデータを使って集計前の対応する行ごとで計算したい

各グループごとでその個別の行の割合を出したいときですね。

これはDataFrame.groupby.applyを使うことで実現できます。

 def calcPercent(x):
    x['Percentage']=x['Value']/x['Value'].sum()
    return x

df_test.groupby(by=["Label"]).apply(calcPercent)
  Label Value Percentage
0 A 50 0.263158
1 A 100 0.526316
2 A 40 0.210526
3 B 80 0.888889
4 B 10 0.111111
5 C 120 1.000000

集計後のデータを集計前の対応する行に追加したい

こちらも言葉で説明するとわかりにくいので実際に以下を例にしてみます。
Labelごとで集計した合計値を元のデータフレームに追加する。

さきほどよりシンプルですが、これはDataFrame.groupby.transformを使うことで実現できます。

df_test["Total"]=df_test.groupby(by=["Label"])["Value"].transform('sum')
  Label Value Total
0 A 50 190
1 A 100 190
2 A 40 190
3 B 80 90
4 B 10 90
5 C 120 120

列ごとで異なる集計をしたい

言葉の通りですね。

これはDataFrame.groupby.aggregateを使うことで実現できます。
列名と集計方法のDictonaryをaggregateに渡します。

df_test=pd.DataFrame([['A',50,10],['A',100,20],['A',40,30],['B',80,40],['B',10,50],['C',120,60]],columns=['Label','Value','Value2'])
df_test.groupby(by=["Label"]).aggregate({'Value':'sum','Value2':'mean'})
　　　Value Value2
Label
A　　 190 20
B　　 90 45
C 　　120 60

一つの列に対して異なる集計をしたい

これもDataFrame.groupby.aggregateを使うことで実現できます。
集計方法のListをaggregateに渡します。

df_test=pd.DataFrame([['A',50],['A',100],['A',40],['B',80],['B',10],['C',120]],columns=['Label','Value'])
 df_test.groupby(by=["Label"]).aggregate(['sum','max'])
  　　Value
　　sum max
Label
A 　190 100
B　 90 80
C 　120 120

以上です。

パッチ管理 vs 脆弱性管理

はじめに

脆弱性管理が大事だという話は当ブログでもさせていただきました。脆弱性管理は大事だからパッチを適切に適用しましょうという話をよくききますが、パッチ管理と脆弱性管理は同じものでしょうか？

パッチ管理は脆弱性管理のための一つの手法にすぎません。パッチ管理を実施していれば問題ないことはなく、脆弱性管理も実施することが望ましいです。

パッチ管理と脆弱性管理

パッチ管理

パッチ管理とは以下の一連のプロセスをさします。

1. ベンダーからパッチの配布
2. パッチのテスト
3. パッチの適用

端的にいうと、利用しているシステムのベンダーの配布する最新のパッチを速やかに入手し本番のシステムに適用して問題ないか確認したうえで適用する作業です。「1.

ベンダーからパッチの配布」にあるように、ベンダーからパッチがでるまで対応を行えません。このため、パッチ管理はリアクティブな対応である点をご注意ください。

脆弱性管理

脆弱性管理とは以下の一連のプロセスをさします。

1. 脆弱性の特定（ペネトレーションテストやスキャン等の実施）
2. 脆弱性の緩和策の実施
3. 脆弱性の根本対策の実施（パッチ適用など）

「1.脆弱性の特定」で積極的に脆弱性を探しにいくところから始まっており、脆弱性管理はプロアクティブな対応といえます。また、パッチではなく脆弱性を対象にしてる点も注目すべき違いです。脆弱性とはソフトウェアのバグによるものもあれば、設定によるものもあります。前者に関してはパッチを適用することによって修復されますが、後者は設定の変更が必要になります。また、すべての脆弱性に必ずしもパッチが存在するとも限りませんし、すぐにパッチを適用できるとも限りません。このようなことから脆弱性の速やかな把握と緩和策の実施が重要になります。

パッチ管理ツールと脆弱性管理ツール

前節ではその定義から違いをご紹介しましたが、実際にそれぞれのツールを見てみるとその違いがよくわかると思います。

パッチ管理ツール

以下が著名なパッチ管理ツールです。

• Microsoft WSUS(Windows Server Update Services)
• IBM Bigfix

これらは各端末のパッチ適用状況を把握しパッチの配布も可能なツールです。管理者の負荷軽減にも役立つツールといえるでしょう。ただし前述したようにあくまでパッチの適用だけであり、脆弱性が網羅されるわけではありません。

脆弱性管理ツール

以下が著名な脆弱性管理ツールです。

• Qualys VM
• tenable nessus

これらはパッチの適用までは行いません。あくまでシステムに存在する脆弱性の特定までを行います。特定された脆弱性に対応するのは管理者の役目です。各脆弱性の深刻度も提示されるため、それを元に必要なパッチ適用のみ実施するという運用が可能です。

まとめ

パッチ管理と脆弱性管理は目的は共通しており似ているところも多いけれど、その対象が異なります。脆弱性管理のうちの一つがパッチ管理と認識いただければと思います。

「役に立たないけど意味がある」って意味が分からない

はじめに

以下の記事を読みました。正直ぜんぜん納得できませんでした。ただブランド戦略やニッチ戦略をいっているようにしか聞こえない・・・。発表者の本を読めば理解できるのかもしれませんが、ちょっとこの話だけ聞くと読む気にもならないレベルです。以下疑問に思った点を述べていきたいと思いますが、理解が間違っている等あれば教えてください。

そもそも「役に立つ」→「意味がある」では？

言葉の使い方がいまいちというところなんですが、役に立つものは意味があるでしょうと。記事中に、マーケティング用語としての情緒的な便益とか自己実現的便益の話をしていますが、もともと何らかの形で「役に立つ」からこそ誰かにとって「意味のある」ものになるのではないでしょうか？スーパーカーもその馬力がまず第一に「役に立つ」機能としてあって初めて魅力的なものになるんじゃないかと。エルメスのバッグも同様、もともと品質の高さがあった上での「意味がある」でしょう。

意味があるって結局ブランド力？

スーパーカーや高級ブランドのバッグは、それを所有することによる優越感、ステータスというのがあります。それは自己実現的便益であるというのはその通りですが、結局ブランドじゃないかと。記事中の以下の文がまさにそれを象徴しているように思います。てか、日本車のLexusにBMWとかより私は乗りたいぞ。

もちろん移動手段として買ってるっていう側面が強いんですけれども、役に立つだけだったら日本車買えばいいじゃないかって言うと、「いやいや、やっぱり俺はBMWが好きなんだ」とか「やっぱりポルシェが好きなんだよね」

結局「この商品もっている俺カッコいい」とかの世界であり、ブランド戦略となにが違うんだろうという。

タバコは「意味がある」商品なのか？

コンビ二に200種類ものタバコの種類があることをもって、タバコは「意味がある」商品であるといっています。

200種類ものタバコがあることには驚きですが、意味があるから200種類になったんですかね？違うでしょ、タバコは中毒性の高いものだから一旦タバコ吸わせたらロングユーザーになるからじゃないですか？新しいユーザ層取り込みのための新商品開発（女性向けとかライトユーザ向けとか）を繰り返して今の形になっているんでしょうよ。いったんユーザになった人は利用し続けるので、継続して作り続けるだけの経済的メリットが提供者にあるだけかと思います。

「意味がある」はサステイナブル？

記事中で「意味がある」は「役に立つ」よりサステイナブルであるといっています。本当にそうでしょうか？

「意味がある」は情緒的や自己実現的なものであるからこそ、そのブランドや商品に対する世の中のイメージで左右されてしまいます。一つの不祥事で容易にそのブランドは凋落しえます。また、不祥事でなくてもブランド戦略を間違えるだけで簡単に凋落しうる危ない橋のように思います。以下の記事の話も非常によい例なのではないでしょうか？

まとめ

私の理解力不足なのかもしれませんが、全体的に共感のできない元記事でした。

私の意見に対して賛否両論あるとは思います。モヤモヤしているのでご意見いただけますと助かります。