エンジニアグループ

FreeCAD 熱解析ガイド⑥ 複合材料の温度シミュレーション精度を検証 - 個人的にCAE...

2025-03-21T20:06:55+09:00

以前のブログに書いたFreeCAD FEMワークベンチによる複合材料の温度シミュレーション方法の妥当性を検証するため、材料の異なる2枚の板を接合したモデルで温度シミュレーションを行い、手計算結果と比較してみた。

2枚の板の大きさや物性値は以下の通り。

◯1枚目
・大きさ（S1）：10×10 [mm]
・厚さ（d1）：1 [mm]
・熱伝導率（k1）：100 [W/m･K]

◯2枚目
・大きさ（S2）：10×10 [mm]
・厚さ（d2）：2 [mm]
・熱伝導率（k2）：50 [W/m･K]

1枚目を上にして2枚を接合する。

また、境界条件は以下の通り。

・初期温度（T0）：300 [K]
・温度拘束（Tb）：2枚目の下面全面で300 [K]
・熱流束（Q）：1枚目の上面全面から100 [W]（1 [MW/m²])

この条件で1枚目の上面の温度T1と1枚目と2枚目の接合面の温度T2の定常値を算出する。

まずは手計算から。

1枚目の熱抵抗Rth1は、

　Rth1=d1/(k1･S1)=1×10^-3/(100×10×10×10^-6)=0.1 [K/W]

2枚目の熱抵抗Rth2は、

　Rth2=d2/(k2･S2)=2×10^-3/(50×10×10×10^-6)=0.4 [K/W]

1枚目と2枚目の合成熱抵抗Rthは、

　Rth=Rth1+Rth2=0.5 [K/W]

ゆえに1枚目上面の温度T1は、

　T1=Q･Rth+Tb=100×0.5+300=350 [K]

となる。

また、1枚目と2枚目の接合面の温度T2は、

　T2=Q･Rth2+Tb=100×0.4+300=340 [K]

となる。

次に、FreeCAD FEMワークベンチを使って同物性値、同境界条件で定常の温度シミュレーションを実施。

その結果、1枚目の上面温度は350 [K]、1枚目と2枚目の接合面の温度は340 [K]と計算され、手計算と同じ結果が得られた。

簡単なモデルではあるが、複合材料の温度シミュレーションは以前のブログで示したようにPartワークベンチでBooleanFragmentsやコンパウンドフィルターの作業を行うことにより、FEMワークベンチで妥当性のある結果が得られると考えられる。

一方で前回のブログでも書いたようには、このシミュレーション方法のうち、BooleanFragmentsの ‘Mode’ を ‘Standard’ から ‘Compsolid’ へ変更することやコンパウンドフィルターを実行することを行わなくても’FEM’ ワークベンチで解析することは可能である。その結果を以下に示す。

結果は、BooleanFragmentsの ‘Mode’ を ‘Standard’ から ‘Compsolid’ へ変更してコンパウンドフィルターを実行した場合と全く同じである。メッシュ作成時も何ら問題も発生しなかった。今回のモデルは簡単な2層の複合材料のために問題が生じなかったのかもしれないので、今後はより複雑で大きなモデルで検証していこうと思う。

GoogleのGemini大幅アップデート：AIの画像生成能力が新次元へ - エンジニアの思い立ったが吉日

2025-03-21T20:00:00+09:00

Googleが今月、人工知能モデル「Gemini」の大幅アップデートを発表し、AI業界に新たな波を起こしています。このアップデートでは特に画像生成・修正技術に大きな進化が見られ、クリエイティブ分野でのAI活用がさらに加速しそうです。

今回のアップデートの目玉は、先進的な画像生成・修正技術の実装です。従来のAI画像生成と比較して、より精細で自然な画像を生成できるようになっただけでなく、既存の画像に対する修正や加工の精度も大幅に向上しました。例えば、写真の不要な部分を削除したり、特定の要素だけを変更したりといった細かな編集が、より自然な仕上がりで可能になっています。

また、GoogleのAIスタジオの機能も拡張され、より直感的なインターフェースでAIの画像生成機能を活用できるようになりました。プロのデザイナーだけでなく、一般ユーザーでも高品質な画像生成が手軽に行えるよう設計されており、AIの民主化が一歩進んだと言えるでしょう。

さらに注目すべきは、Deep Research機能の改善です。この機能は、ユーザーの質問に対してより深く、正確な回答を提供するためのもので、今回のアップデートでは情報の正確性と網羅性が向上しました。特に専門的な分野や学術的な内容に関する質問への対応力が強化されており、研究者や専門家にとっても頼りになるツールとなっています。

GoogleがこのタイミングでGeminiの大幅アップデートを発表した背景には、OpenAIのChatGPTやAnthropicのClaudeなど、競合AIモデルとの激しい競争があります。特に画像生成分野では、MidjourneやStable Diffusionなどの専門AIとの差別化を図る狙いもあるでしょう。

このアップデートにより、Googleは総合的なAIプラットフォームとしての地位を強化し、検索エンジンからAIアシスタント、クリエイティブツールまでをシームレスに提供する戦略を進めています。今後は、これらの機能がGoogle WorkspaceやAndroidなどの既存製品にどのように統合されていくのかも注目ポイントです。

ユーザーにとっては、より高度な画像生成能力と情報検索能力を備えたGeminiが、日常生活やビジネスシーンでの活用の幅を広げてくれることでしょう。クリエイティブ作業の効率化や、複雑な情報の整理・分析など、様々な場面でのサポートが期待されます。

記事を書いた人

IT関連の時事ネタ、気になるAIサービス、ローコード・ノーコードなど、新しく気になるサービス・情報を発信していきます。
エンジニアの継続的な学習と成長を促進し、新しい挑戦へのお手伝いをします

応援していただけるとスゴク嬉しいです！

読者になる

ランキング参加中

【公式】2024年開設ブログ

ランキング参加中

ブログ仲間増やしたい方全員集合！✨　初心者も上級者も誰でも参加OK！

ランキング参加中

エンジニアグループ

AIモデルの訓練で時給4500円、米国の「大卒副業ワーカー」が直面する現実 - 元スマホエンジニアのニュース雑記

2025-03-21T17:30:00+09:00

AIの訓練と言えば途上国の画像アノテーションのイメージでしたが、最近の訓練はかなり高度化しているようですね。

専門性を活かせるなら、副業としては結構良さそうです。

M/M/1の印刷時間を計算 - SLnavkのブログ

2025-03-20T22:57:19+09:00

問題

プリントシステムには1時間当たり平均6個のファイルのプリント要求がある。1個のプリント要求で送られてくるファイルの大きさは平均7,500バイトである。プリントシステムは1秒間に50バイト分印字できる。プリント要求後プリントが終了するまでの平均時間は何秒か。ここで，このシステムはM/M/1の待ち行列モデルに従うものとする。

ア. 150
イ. 175
ウ. 200
エ. 225

_{出典: 令和3年春期午前Ⅱ 問23}

爆速解法

平均処理時間は 7500/50 = 150 秒
利用率は 150/600 = 1/4
以上から、要求後から印刷完了までの平均時間は
よって、ウの200秒。

じっくり解説

平成29年秋期午前Ⅱ 問23に類題あり。以下参照。

プリンターの平均印刷時間 - SLnavkのブログ

【体験談】半年間のキャリアコーチングを走りきって得られたもの - Halcyon Days

2025-03-20T17:37:39+09:00

2024年9月から2025年3月の約半年間、キャリアコーチングを受けていたのでその感想をば。

先に成果をお伝えしたほうがいいかなと思うので、お伝えしておきます。

この半年間のキャリアコーチングで

ずっと住みたかった四国への移住が決まった
転職に成功し、やりたかったDX推進のポジションへキャリアチェンジ
年収が100万円ほどアップし、待遇も大幅に向上

という半年前では考えられなかった成果を手にできました。

30歳までにこれくらい欲しいと思った年収に乗せることができ、移住も決まり、やりたかったことを仕事でできるようになりました。

そんな成果を手にできたのはキャリアコーチングがあったからだと思っています。

もし、キャリアコーチングを受けていなかったら半年前と同じように得体のしれないモヤモヤを抱えながら仕事をしていると思います。

そのキャリアコーチングを受けた感想エントリです。

本エントリは

なぜキャリアコーチングを受けようと思ったか
キャリアコーチングとは
どのキャリアコーチングサービスを選んだか
キャリアコーチングを受けて得られたもの

を書きます。

一方で、

実際に受けたキャリアコーチングの内容
キャリアコーチングサービスの比較
キャリアコーチングと転職エージェントの違い

みたいなトピックには触れていませんのでご了承ください。

なぜキャリアコーチングを受けようと思ったか
キャリアコーチングとは？
どのキャリアコーチングサービスを選んだか
- サービスの選び方
- 私が選択したサービス
キャリアコーチングを通して得られたもの

なぜキャリアコーチングを受けようと思ったか

まず、私がなぜキャリアコーチングを受けようと思ったかですが、

自分に適した仕事を20代のうちに見つけておきたかったから

です。

人生100年時代や定年延長などが言われているこの世の中で、労働の期間はあり得ないくらい長いです。

~~たまに定年までの期間を考えて鬱になります。~~

「どうせそんなに長い期間働くんだったら、自分がやっていて面白いと思うこと、やりたいと思うことをやったほうがいい」

「1日の3分の1をつまらないと思って過ごしたくはない」

25歳の時に公務員を辞めてレールから外れた時、このような思いを抱いていました。

しかし、キャリアも浅く、経験も少ない自分がそんな「天職」のような仕事を見つけられるわけでもなく、職を転々とするジョブホッパーみたいな生き方をしていました。

周りは結婚・子育て・昇進など、着々と人生のコマを進めている一方で、自分はまだマサラタウンから出られていない感じだったのです。

そのような現状を打破したいとは常日頃思っていましたが、

「どうやればいいのだろう」

「これでいいのだろうか」

「やって駄目だったらどうしよう」

との思いから行動に移せていませんでした。

そのような中で、すがるような思いで始めたのがキャリアコーチングでした。

キャリアコーチングとは？

「キャリアコーチングって何？」と思う人もいると思うのでこの疑問の解消をしておきましょう。

キャリアコーチングをサービスとして取り扱っている数社の記事から引用します。

株式会社MIZUKARA様

キャリアコーチングは、キャリアコーチが個別にサポートし、「無意識の自己理解」を特定することで、自分のキャリア目標を明確化し、その実現に向けた具体的なプランを一緒に考えるサービスです。

キャリアコーチングのリアルな体験談は？｜受講者の口コミを紹介 | 今日も最高の1日に

アクシス株式会社様

キャリアコーチングとは、キャリアに関することであれば、なんでも相談することができる、いわば「キャリアのかかりつけ医」です。

キャリアコーチングとは？おすすめ12選の料金・体験談と失敗しない選び方を紹介！

株式会社キャリア・エックス様

「キャリアコーチング」は、キャリアのプロと一対一で対話することで、一人ひとりが持ち味を活かし、納得のいくキャリアを歩めるようにサポートするサービスのことです。

キャリアコーチングとは？失敗しない選び方4選！デメリットやエージェントとの違いも解説 | 株式会社キャリア・エックス

まとめると、自分の理解や理想のキャリア明確化、アクションプランの作成などをするために帆走してくれるキャリアのプロというところでしょうか。

野球やテニスのコーチのキャリア版みたいなイメージでいいかと思います。

多くの企業が体験コーチングをしているので、興味のある方はぜひ受けてみるといいと思います。

私が受けていた方も体験を行っているので、後で紹介しますね。

どのキャリアコーチングサービスを選んだか

サービスの選び方

どのサービスにするか迷いますよね。

特に最近はキャリアコーチングサービスが流行りで、多くの企業が多様なサービスを展開していますから。

自分のようにありすぎて選べない人もいるかと思います。

なのでまずは、自分がキャリアコーチングに何を求めるのかをはっきりさせるといいと思います。

ここではっきりさせた求めるもので、サービスを選択すればいいと思います。

たとえば、「自分の強みを特定して強みを活かして働きたい」と思ってキャリアコーチングを受けるのなら株式会社MIZUKARA様のキャリスピやポジウィル株式会社様のポジウィルキャリア、株式会社カメレオン様のキャリドラなどになるでしょう。

コスパよく受けたいでも構いませんし、長期間にわたって継続して受けたいとかでもいいでしょう。

なので、まずはキャリアコーチングに何を求めるのかをはっきりさせてみてください。

コーチングは非常に高額です~~（なぜこんなに高額なのかわからないくらいに高額）~~。

なので、受けて「やっぱ違った」は取り返しのつかないことになります。

そうならないためにもしっかりと求めるものは決めておきましょう。

私が選択したサービス

自分は企業のサービスではなく、伊藤祐矢さん（以下、Yuyaさん）というフリーランスの方が提供されているサービスを選びました。

yuyaito.com

Yuyaさんを選んだ理由は

認知科学を用いたコーチングを行っていること
やって終わりになっていたストレングスファインダーを考慮できること
できるだけ価格が抑えられること

でした。

それでもポジウィルキャリアと迷っていて、どちらも体験を受けていましたね……。

最後の決め手は、Yuyaさんのnoteを読んで「この人なら信頼できる」と感じたこと、あとはビジョンとミッションが共感できたからでした。

note.com

あと、体験談も参考にしました。

（記事見つけられなかったので見つけたら貼ります！！）

キャリアコーチングを通して得られたもの

まず、キャリアコーチングを受けて得られたものですが、

現時点での理想のゴール
決めきるという大切さ
行動

の3つだと思っています。

現時点での理想のゴール

ゴールは常に更新され続けるものなので現時点でのものですが、私は下記のようなゴールを設定しました（めちゃくちゃ定性的ですが）。

人生のテーマ：穏やかに、軽やかに、ありのままで生きること人生のゴール：心豊かな人を増やすこと仕事のゴール：専門職の人が働きやすい職場環境を作ること人間関係のゴール：こいつなら何でも話せるような存在になること趣味のゴール：自分の好きを通して人々に豊かさを与えること社会貢献のゴール：心病める人を1人でも多く救うことお金のゴール：明日の生活を心配せず、自分にもパートナーにも制限を感じさせない資産があること知性・学問のゴール：働きやすい職場環境の専門家になること美容・健康のゴール：常に若々しく、瑞々しい心身であること家族のゴール：対話を通してお互いを受け入れ、お互いがありのままで過ごせる関係性を築くこと

「人生のテーマ」だけは自分で加えたものですが、自分らしさが入ったゴールになったかなと。

これらは最上位で、これらの下に定量的なゴール、たとえば年収はいくらで〜、が設定されています。

決めきる大切さ

正直、これがキャリアコーチングで得られたものの中で最も良かったものだと思っています。

移住も転職も決めきったことで一気に進んだと感じています。

たとえば移住は、昨年の9月頃までは「30歳までに四国に行ければいいな〜」と思っていました。

なんとなく期日を立てて、なんとかなるやろ精神で過ごしていたのです。

そのような中で昨年の11月に四国へ旅行に行って、実際に目で見て体感してきたことで「来年の8月31日までにここに住む」という決断をしました。

この決断のお陰でやるべき行動が定まり、転職活動を半年前倒してスタートしました。

そのおかげか、たまたま次の会社とのこ゚縁が生まれ、まるで未来から時間が流れてくるかのように、トントン拍子で（自分でもびっくりするくらい早い）転職と移住が決まりました。

自分でもびっくりするくらいあっさりときまったのでびっくりしています……笑

行動

キャリアコーチングを受けて2〜3ヶ月ほど経った時に、受けているだけでなにも変わっていないと気づきました。

実際にコーチはコーチングをしてくれますが、行動するのはあくまでも自分です。

なので、自分が行動をしなければ、当たり前ですが、物事は前に進みません。

この感覚を抱いて、自分のこれまでを作ってきたのは行動しなかった自分だと気づきました。

先に、

「どうやればいいのだろう」

「これでいいのだろうか」

「やって駄目だったらどうしよう」

との思いからこれまで行動できていなかったと書いていましたが、やはりコーチングを受ける中でも同じ思いを抱きました。

なので、Yuyaさんに思い切ってこの事実を相談し、ゴールに向かう行動について教えを請ってみたのです。

このままでだめだと思っていた自分がいたからです。

教えに忠実に、小さいアクションを仕事で続けてみた結果、ソフトウェア開発のテスト責任者になることができました。

行動する大切さ、かつゴールに向かうアクションの考え方などはこれからも続けていきます。

キャリアコーチングを受けてみて

半年間という長いような短いような期間の中で、自分の求めていた以上の成果を出せたのはコーチがいなかったら在り得なかったと思います。

なので、現状にモヤモヤしていたり、もっとできると思っている方はぜひキャリアコーチングを受けるといいかもしれません。

人生の大半を費やす仕事が楽しかったら、人生はもっと楽しくなる、そう思いませんか？

そのような思いがある人はぜひ思い切って飛び込んでみてください。

半年前にコーチングを受講すると決めた自分、11月に四国に住むと決めた自分、そして半年間走りきった自分を褒めてあげたいです。

私は夏から移住・転職と新しい環境に移ります！

今から楽しみです！　Yuyaさん本当にありがとうございました！

久々に書いたぞ〜〜〜！

ランキング参加中

雑談・日記を書きたい人のグループ

リスク中心の脅威モデリング手法！TRIKEとは？DFDを活用した分析を解説 - 城咲子｜情シスセキュリティ担当のつぶやき（ぼやき）

2025-03-20T17:33:29+09:00

TRIKEとは？
TRIKEの主な特徴
TRIKEのプロセス
TRIKEの利点
まとめ

脅威モデリングは、システムに対する潜在的な脅威を特定し、対策を講じるための重要なプロセスです。数ある脅威モデリング手法の中でも、リスク中心のアプローチを採用した「TRIKE」は、特にデータフロー図（DFD）を用いた分析に重点を置いています。

今回は、TRIKEの基本概念から特徴、プロセス、そして利点まで、分かりやすく解説します。

TRIKEとは？

TRIKEは、リスク中心のアプローチを採用した脅威モデリング手法です。オープンソースのセキュリティ監査フレームワークとして開発され、特にデータフロー図（DFD）を用いた分析に重点を置いています。

つまり、システムに対する脅威を「リスク」として捉え、DFDを用いて分析することで、より効果的な脅威対策を実現する手法です。

TRIKEの主な特徴

リスク中心のアプローチ:
- 脅威だけでなく、リスク評価を重視し、優先順位付けを行います。
データフロー図（DFD）の活用:
- システムのデータフローを可視化し、脅威の侵入経路や影響範囲を特定します。
アクターとアクションの分析:
- システムに関わるアクターと、各アクターが実行可能なアクションを分析します。
許容可能なリスクの定義:
- 組織が許容可能なリスクレベルを定義し、脅威対策の必要性を判断します。

TRIKEのプロセス

TRIKEは、以下のプロセスで実施されます。

システムの定義:
- システムの境界、コンポーネント、インターフェースなどを明確にします。
データフロー図（DFD）の作成:
- システムのデータフローを可視化します。
アクターとアクションの列挙:
- システムに関わるアクターと、各アクターが実行可能なアクションを列挙します。
脅威の特定:
- DFDとアクター/アクション分析に基づいて、潜在的な脅威を特定します。
リスク評価:
- 各脅威のリスクレベルを評価し、優先順位付けを行います。
対策の策定:
- リスクの高い脅威に対して、適切なセキュリティ対策を検討し、実装します。
リスクの許容度定義:
- それぞれの脅威箇所に利用者が触れられるかどうかを5段階で評価します。

TRIKEの利点

リスクベースのアプローチにより、効率的な脅威対策が可能。
DFDを活用することで、システムのデータフローに潜む脅威を可視化。
アクターとアクションの分析により、不正な操作や攻撃シナリオを想定。
許容可能なリスクレベルを定義することで、コストとリスクのバランスを取る。

まとめ

TRIKEは、特にデータフローが複雑なシステムや、リスクベースの脅威モデリングを重視する場合に有効な手法です。TRIKEを活用することで、より効果的な脅威モデリングを実現し、システムのセキュリティを向上させましょう。

VPC、サブネット、セキュリティグループの違い - プログラミング学習サイト

2025-03-20T16:38:37+09:00

VPCとは何か?

VPCとは仮想ネットワークです。ひとつのAWSアカウントを論理的に分離することができる仮想ネットワークで AWS リソースを起動できるようになります。

VPCの全体像は以下の通りです。

VPCはさらに細かい サブネット という小さいネットワークに分割することができます。サブネットにはパブリックサブネットとプライベートサブネットの2種類があります。これらの領域に分割することで、セキュリティを担保できるのです。

パブリックサブネット: 直接インターネットアクセスが可能なサブネット。
プライベートサブネット: インターネットアクセスが制限されているサブネット。

VPCのIaCコードサンプル

ProductVPC:
  Type: AWS::EC2::VPC
  DeletionPolicy: Delete        # Deleteは、スタックが削除されるときにVPCも削除することを意味します。
  Properties:
    CidrBlock: 172.16.0.0/16    # VPCのCIDRブロックを指定します。CIDRブロックはVPC内のIPアドレスの範囲を定義します。
    EnableDnsSupport: 'true'
    EnableDnsHostnames: 'true'
    InstanceTenancy: default    # VPC に起動されたインスタンスは、インスタンスの起動時に別のテナンシーを明示的に指定しない限り、デフォルトで共有ハードウェア上で実行されます。基本はデフォルトを指定する。
    Tags:
    - Key: Name
      Value: ProductVPC

CidrBlock: 172.16.0.0/16
- CIDRブロックはVPC内部で取れるIPアドレスの範囲です。
- 上記のCIDRブロックを次のサイトに入力すると、IPアドレスのとりうる範囲がわかります。
- https://www.rohde-schwarz.com/jp/solutions/cybersecurity/landing-pages/cidr-calculator_256249.html
- 172.16.0.0 ... 172.16.255.255
- Amazon VPCに割り当てるIPv4のCIDRブロックですが、AWSではRFC 1918 で定義されているプライベートIPアドレスの範囲を推奨しています。
  - ・10.0.0.0/8 （10.0.0.0 ～ 10.255.255.255）
  - ・172.16.0.0/12 （172.16.0.0 ～ 172.31.255.255）
  - ・192.168.0.0/16 （192.168.0.0 ～ 192.168.255.255）
- Amazon VPCの仕様により、割り当てられるCIDRブロックサイズは/16～/28のサイズにする必要があります。
- IPアドレスが少ない方が立てれるサーバーの数が減ってセキュリティ面で強くなったりしますが、
InstanceTenancy: default:
- 基本はデフォルトを選んでおこう

AWS Subnet

VPCを細かく分割したのがサブネットです。サブネットは「プライベートサブネット」「パブリックサブネット」などインターネットに対して開いている、閉じているなどを設定することができます。

パブリックサブネット: 直接インターネットアクセスが可能なサブネット。
プライベートサブネット: インターネットアクセスが制限されているサブネット。
- また、パブリックサブネットには インターネットゲートウェイ と呼ばれるインターネットに接続できるサービスを設定できます。

具体的にはサブネットをプライベート、パブリックたらしめているものは、ルートテーブルの設定と、その中でのインターネットゲートウェイの使用 そして、ネットワークACLの三つ です。

SubnetのIaC

PublicSubnetA:
  Type: AWS::EC2::Subnet
  DeletionPolicy: Delete
  Properties:
    VpcId: !Ref ProductVPC
    AvailabilityZone: "ap-northeast-1a" # ここを指定しないと海外リージョンに作成されてしまうこともある！
    Tags:
    - Key: Name
      Value: PublicSubnetA

AvailabilityZone: "ap-northeast-1a"
- ここの設定は 日本で開発をするのであればなおさら必須

サブネットのCIDRの決め方

サブネットのCIDRの決め方は、VPCのCIDRの範囲内に収まるようにする！ && 利用するIPアドレスの数次第で決まる!

VPCのCIDRが192.168.0.0/16の時
サブネットのCIDRはその中から切り出すイメージで 192.168.1.0/24を指定する
この場合、利用可能なIPアドレスの数が 251 あることを確認する。 ( ネットマスクが24であるため、残りの8バイト => 0~255個使える。 )
仮に、この中でEC2インスタンスを立てた場合は 192.168.1.???に該当するIPアドレスが プライベートIPアドレス(AWS内部で閉じているIPアドレス) が割り振られる。
- EC2インスタンスのパブリックIPはAWSが適当につけるIPアドレスなので、EC2を起動、停止するたびに変わることに注意

以下プライベートIPアドレスについてのコラム

ちなみに、「192.168.x.x」（192.168.0.0～192.168.255.255）の範囲のIPアドレスは，このプライベート・アドレスにあたる。この範囲のIPアドレスはパブリックなIPアドレスではなく、その他、プライベートIPアドレスとして使える範囲は決められている。「10.0.0.0～10.255.255.255」「172.16.0.0～172.31.255.255」「192.168.0.0～192.168.255.255」である。どれを使うかは、IPアドレスを割り当てるホスト数で決める。同一ネットワークでなければ重複しても構わない。コンソール画面から、EC2のプライベートIPアドレスは

AWSルートテーブルとAWSルート

サブネット内外の通信では、ルートテーブルとルートの二つのリソースを使用する。

ルートテーブルはサブネットのIPアドレスに応じて、どのように通信するかorブロックするかを決めるテーブルであり、ルートはテーブルの行(IPと通信経路の一組の対応)である。

from https://dev.classmethod.jp/articles/subnet-to-subnet-traffic-with-amazon-vpc-more-specific-routing/

AWSのルートテーブル、ルートのIaCコード

パブリックサブネットのルートテーブルの例

インターネットゲートウェイが刺さっているのが確認できる。

RouteTable:
  Type: AWS::EC2::RouteTable
  Properties:
    VpcId: !Ref VPC
    Tags:
      - Key: Name
        Value: PublicRouteTable

PublicRoute:
  Type: AWS::EC2::Route
  Properties:
    RouteTableId: !Ref RouteTable
    DestinationCidrBlock: 0.0.0.0/0
    GatewayId: !Ref InternetGateway

プライベートサブネットのルートテーブルの例

以下の例では、Natゲートウェイを使用してインターネットに接続している例です。

RouteTable:
  Type: AWS::EC2::RouteTable
  Properties:
    VpcId: !Ref VPC
    Tags:
      - Key: Name
        Value: PrivateRouteTable

PrivateRoute:
  Type: AWS::EC2::Route
  Properties:
    RouteTableId: !Ref RouteTable
    DestinationCidrBlock: 0.0.0.0/0
    NatGatewayId: !Ref NatGateway

ちなみに、サブネットとルートテーブルを結びつけるためには SubnetRouteTableAssociation リソースを使用します。

PublicSubnetRouteTableAssociation:
  Type: AWS::EC2::SubnetRouteTableAssociation
  Properties:
    SubnetId: !Ref PublicSubnet
    RouteTableId: !Ref PublicRouteTable

AWS InternetGateway

インターネットゲートウェイはパブリックサブネットとインターネットを繋げるサービスです。以下のように、本体である InternetGatewayと VPCGatewayAttachmentを揃えることでVPCにアタッチすることができます。

InternetGW:
  Type: AWS::EC2:InternetGateway
  DeletionPolicy: Delete
  Propaties:
    Tags:
    - Key: Name
      Value: PublicIGW

AttachmentIGW:
  Type: AWS::EC2::VPCGatewayAttachment
  DeletionPolicy: Delete
  Properties:
    InternetGatewayId: !Ref InternetGW
    VpcId: !Ref ProductVPC

これだけだとVPC内部にインターネットゲートウェイ存在するだけなので、 Pubilcルートテーブルと繋げる必要があります。以下は Routeリソースを使用して 0.0.0.0/0 に対応するリソースとして InternetGatewayを設定することでインターネットと接続することが可能です。

PublicRoute:
  Type: AWS::EC2::Route
  Properties:
    RouteTableId: !Ref PublicRouteTable
    DestinationCidrBlock: 0.0.0.0/0
    GatewayId: !Ref InternetGateway

AWS NetworkACL

ネットワーク内部での動きを制限することが可能です。 NetworkACLはNACL(ナクル)とも呼ばれます。

NACLをサブネットに作成すると以下のコンソール画面のように サブネットと外部の通信を制限することが可能です。

次のサブネットは 0.0.0.0/0(インターネットのIPのこと)から入ってくる通信で、80,443,22を許可してます。その他、10.0.0.0/16 は全ての通信を許可していますが、これはプライベートIPアドレスのことを指しています。

パブリックなNetwork ACLの例

インバウンドルール

ルール番号	許可/拒否	プロトコル	ポート範囲	ソース	説明
100	許可	TCP	22	203.0.113.0/24	SSHアクセス
110	許可	TCP	80	0.0.0.0/0	HTTPアクセスの許可
120	許可	TCP	443	0.0.0.0/0	HTTPSアクセスの許可
*	拒否	全て	全て	全て	デフォルトの拒否ルール

アウトバウンドルール

ルール番号	許可/拒否	プロトコル	ポート範囲	デスティネーション	説明
100	許可	TCP	80	0.0.0.0/0	HTTPアクセスの許可
110	許可	TCP	443	0.0.0.0/0	HTTPSアクセスの許可
120	許可	UDP	53	0.0.0.0/0	DNSクエリの許可
*	拒否	全て	全て	全て	デフォルトの拒否ルール

上記のルールは次のような意味を表しています。

SSH トラフィックの許可: 管理目的でSSH(22)接続を許可しますが、特定のIPアドレス範囲からのみに制限します（例: 管理者のIPアドレスのみ）。今回は(203.0.113.0/24)を許可しています。
- 今回インバウンドルールでSSHを許可しているため、外部のPCから接続することはできますが、アウトバウンドでは拒否されています。これにより、「内部からSSH接続を使用して踏み台サーバーとして利用されること」を防いでいます。
HTTP/HTTPS トラフィックの許可: Webサーバーが配置されることが多いため、HTTP(80)およびHTTPS(443)のトラフィックを許可します。

その他、デフォルトはすべて拒否している状態です。

プライベートなNetworkAClの例

インバウンドルール

ルール番号	許可/拒否	プロトコル	ポート範囲	ソース	説明
100	許可	TCP	22	203.0.113.0/24	SSHアクセス
110	許可	TCP	3306	10.0.0.0/16	データベースアクセス（MySQL）
120	拒否	TCP	80	0.0.0.0/0	HTTPアクセスの拒否
130	拒否	TCP	443	0.0.0.0/0	HTTPSアクセスの拒否
*	拒否	全て	全て	全て	デフォルトの拒否ルール

アウトバウンドルール

ルール番号	許可/拒否	プロトコル	ポート範囲	デスティネーション	説明
100	許可	UDP	53	0.0.0.0/0	DNSクエリ
110	拒否	TCP	80	0.0.0.0/0	HTTPアクセスの拒否
120	拒否	TCP	443	0.0.0.0/0	HTTPSアクセスの拒否
*	拒否	全て	全て	全て	デフォルトの拒否ルール

ネットワークACLのIaCコードの例

PublicNetworkACL:
  Type: AWS::EC2::NetworkAcl
  DeletionPolicy: Delete
  Properties:
    VpcId: !Ref ProductVPC
    Tags:
    - Key: Name

セキュリティグループ

これまでは「ネットワーク」の話をしてきましたが、セキュリティグループは「リソース」に対するアクセス制御です。

NetworkACLがサブネットの制限を行うのに対して
セキュリティグループはリソースの制限を行います

HTTP/HTTPSサーバー向けのセキュリティグループ

インバウンドルール:
- タイプ: HTTP (ポート80)、HTTPS (ポート443)
- プロトコル: TCP
- 許可ポート: 80, 443
- ソース: 0.0.0.0/0 (どこからでもアクセス可能)
アウトバウンドルール:
- 通常はデフォルトですべてのトラフィックを許可するように設定されます。

このセキュリティグループは、WebサーバーなどのHTTPやHTTPSを使用するリソースに適しています。

タイプ	プロトコル	ポート範囲	ソース
HTTP	TCP	80	0.0.0.0/0
HTTPS	TCP	443	0.0.0.0/0
アウトバウンド	すべて	-	-

パブリックなリソースではデータベースのような「外向きに出たら困るもの」はそこまで置いてない(?)ため、アウトバウンドは許可される傾向にあります。

サブネットに合わせるケース

以下はPublicなサブネット内部のリソースに紐付ける想定のサブネットです。

タイプ	プロトコル	ポート範囲	ソース
Public-AZ01	全て	全て	172.16.0.0.0/20
Public-AZ02	全て	全て	172.16.16.0/20
Public-AZ03	全て	全て	172.16.32.0/20

サブネット内部の通信を許可するために、上記のセキュリティグループを紐づけても良いでしょう。

test

具体的な利用手順は以下の通りです。

VPCの作成(AWSのマネジメントコンソールから作成します)
AWS EC2や、Lambda、RDSなどを配置します。
VPC同士の通信方法を定義します。

この3ステップでVPCが利用できます。

VPCのメリットとは何か?

オンプレミス環境でネットワークを構築しようとする場合、サーバーやLANケーブルやスイッチやらルーターやらが必要となります。

ところが、AWS上のコンポーネント(Lambdaや、EC2など)をまとめ、ルーター機能やDNSなどのネットワークで必要なものは全てAWSで保管してくれるのです。

VPCで最も大事なのがCIDRブロック

CIDRブロックとは、VPNを構成する際の一つのパラメーターのことです。

VPN内部で使用できるIPアドレスの数をコントロールすることができます。

例えば、CIDRが10.0.0.0/16であれば、65535個のIPアドレスを使用することができますし
CIDRが10.0.0.0/28であれば、16個のIPアドレスを使用することが可能です

具体的なイメージ例1

EC2を踏み台サーバーとして経由し、データベースを公開する。

備考

title: AWS VPCを1分解説

AWSアソシエイトレベルのソリューションアーキテクト

PowerApps マネージャー確認機能付き執務日報アプリ２ - 情シス仕事の備忘録

2025-03-19T20:00:00+09:00

前の記事の続きになります。

アプリを作成する:編集画面
アプリを作成する:詳細画面
アプリを作成する:確認依頼通知フロー
おわりに

アプリを作成する:編集画面

必要項目の追加、コントロールの種類変更

左側[ツリービュー]の [EditScreen1>EditForm1]を選択し、右側[プロパティ]の[ディスプレイ>フィールド]の[フィールドの編集](環境によっては[8件選択済み])を選択し、[フィールドの追加]を選択します。
[ID]にチェックをつけ、[追加]を選択します。

tasks、good_points、improvement_point、manager_commentについて、コントロールの種類を[テキストの編集]から[複数行テキストの編集]に変更します。

画面タイトル変更、非表示項目の設定

項目IDのDataCardValueXXの番号部分(この例では17)を確認の上、画面タイトルを選択し、以下の通り設定します。
・Textプロパティ："執務日報 (ID:" & DataCardValue17.Text & ")"
これにより、画面タイトルにIDの値が表示されるようになります。
なお、この後も項目の値により表示や色などを制御する式を多く設定します。DataCardValueの番号部分は左ツリーで確認してください。

項目IDの全体領域を選択し、右側プロパティの[ディスプレイ>表示]をオフにしておきます。
これにより、項目IDが編集エリアで非表示になります。

項目のレイアウト調整

少々扱いに癖がありますが、各項目の全体領域を選択し、右側[プロパティ]の[詳細設定]の下の方にある、[Height]、[Width]、[X]、[Y]に値設定すると意図したレイアウトになります。
・0行目：working_day(幅320),status(幅320,X320)
・1行目：reporter(幅320),manager(幅320,X320)
・2行目：tasks(幅640)
・3行目：good_points(幅640)
・4行目：improvement_points(幅640)
・5行目：manager_comment(幅640)

各項目の設定(表示モード、入力必須、初期値)

この例では、データのステータスやアプリユーザーの役割に応じて表示モード・入力必須を切り替えます。また、報告日からマネージャーまでは初期値を設定します。

まずは報告日(working_day)を設定します。
全体領域を選択し、右クリックで[ロック解除]を選択の上、以下の通り設定します。
・DisplayModeプロパティ：If(DataCardValue10.Text=User().FullName && DataCardValue11.Selected.Value="下書き", DisplayMode.Edit, DisplayMode.View)
※報告者がアプリユーザーかつステータスが下書きの場合は編集モード、それ以外は閲覧モードとします
・Requiredプロパティ：If(DataCardValue10.Text=User().FullName && DataCardValue11.Selected.Value="下書き", true, false)
※報告者がアプリユーザーかつステータスが下書きの場合は入力必須、それ以外は任意とします

続けてデータ領域を選択し、以下の通り設定します。
・DefaultDateプロパティ： If(EditForm1.Mode = FormMode.New,Today(),ThisItem.working_day)
※新規登録時は今日の日付を設定し、それ以外は既存の値を設定します
・Fillプロパティ：If(DataCardValue10.Text=User().FullName && DataCardValue11.Selected.Value="下書き", RGBA(255, 255, 255, 1), RGBA(166, 166, 166, 1))
※報告者がアプリユーザーかつステータスが下書きの場合は背景色を白色、それ以外は灰色にします
・Sizeプロパティ：21

次はステータス(status)を設定します。
全体領域を選択し、右クリックで[ロック解除]を選択の上、以下の通り設定します。
・DisplayModeプロパティ：DisplayMode.View
※ステータスはユーザーが値を指定するのではなく、保存⇒確認依頼⇒確認処理に応じて自動更新するため、閲覧モードとします

続けてデータ領域を選択し、以下の通り設定します。
・DefaultSelectedItemsプロパティ：If(EditForm1.Mode = FormMode.New,Choices([@執務日報].status,"下書き"),ThisItem.status)
※新規登録時は”下書き”を設定し、それ以外は既存の値を設定します
・Fillプロパティ：RGBA(166, 166, 166, 1)
※背景色を灰色にします

報告者(reporter)を設定します。
全体領域を選択し、右クリックで[ロック解除]を選択の上、以下の通り設定します。
・DisplayModeプロパティ：DisplayMode.View
※報告者は自動取得するため、閲覧モードとします

続けてデータ領域を選択し、以下の通り設定します。
・Defaultプロパティ： If(EditForm1.Mode = FormMode.New,User().FullName,ThisItem.reporter)
※新規登録時はアプリユーザーの表示名を設定し、それ以外は既存の値を設定します
・Fillプロパティ：RGBA(166, 166, 166, 1)
※背景色を灰色にします

マネージャー(manager)を設定します。
全体領域を選択し、右クリックで[ロック解除]を選択の上、以下の通り設定します。
・DisplayModeプロパティ：DisplayMode.View
※マネージャーは自動取得するため、閲覧モードとします

続けてデータ領域を選択し、以下の通り設定します。
・Defaultプロパティ： If(EditForm1.Mode = FormMode.New,glb_manager,ThisItem.manager)
新規登録時は前の記事の工程5で定義したグローバル変数(アプリユーザーのマネージャーの表示名、マネージャー不在の場合は本人の表示名)を設定し、それ以外は既存の値を設定します
・Fillプロパティ：RGBA(166, 166, 166, 1)
※背景色を灰色にします

業務内容(tasks)を設定します。
全体領域を選択し、右クリックで[ロック解除]を選択の上、以下の通り設定します。
・DisplayModeプロパティ：If(DataCardValue10.Text=User().FullName && DataCardValue11.Selected.Value="下書き", DisplayMode.Edit, DisplayMode.View)
※報告者がアプリユーザーかつステータスが下書きの場合は編集モード、それ以外は閲覧モードとします
・Requiredプロパティ：If(DataCardValue10.Text=User().FullName && DataCardValue11.Selected.Value="下書き", true, false)
※報告者がアプリユーザーかつステータスが下書きの場合は入力必須、それ以外は任意とします

続けてデータ領域を選択し、以下の通り設定します。
・Fillプロパティ：If(DataCardValue10.Text=User().FullName && DataCardValue11.Selected.Value="下書き", RGBA(255, 255, 255, 1), RGBA(166, 166, 166, 1))
※報告者がアプリユーザーかつステータスが下書きの場合は背景色を白色、それ以外は灰色にします

良かった点(good_points)を設定します。
全体領域を選択し、右クリックで[ロック解除]を選択の上、以下の通り設定します。
・DisplayModeプロパティ：If(DataCardValue10.Text=User().FullName && DataCardValue11.Selected.Value="下書き", DisplayMode.Edit, DisplayMode.View)
※報告者がアプリユーザーかつステータスが下書きの場合は編集モード、それ以外は閲覧モードとします

続けてデータ領域を選択し、以下の通り設定します。
・Fillプロパティ：If(DataCardValue10.Text=User().FullName && DataCardValue11.Selected.Value="下書き", RGBA(255, 255, 255, 1), RGBA(166, 166, 166, 1))
※報告者がアプリユーザーかつステータスが下書きの場合は背景色を白色、それ以外は灰色にします

反省点(improvement_points)も上記と同じ要領で設定します(画面イメージは割愛します)。

最後に、マネージャーコメント(manager_comment)を設定します。
全体領域を選択し、右クリックで[ロック解除]を選択の上、以下の通り設定します。
・DisplayModeプロパティ：If(DataCardValue15.Text=User().FullName && DataCardValue11.Selected.Value="確認待", DisplayMode.Edit, DisplayMode.View)
※マネージャーがアプリユーザーかつステータスが確認待の場合は編集モード、それ以外は閲覧モードとします

続けてデータ領域を選択し、以下の通り設定します。
・Fillプロパティ：If(DataCardValue15.Text=User().FullName && DataCardValue11.Selected.Value="確認待", RGBA(255, 255, 255, 1), RGBA(166, 166, 166, 1))
※マネージャーがアプリユーザーかつステータスが確認待の場合は背景色を白色、それ以外は灰色にします

保存アイコンの設定変更

右上の保存アイコンが確認処理と間違えそうなのでイメージを変更します。
右上のアイコンを選択し、右側プロパティの[ディスプレイ>アイコン]のリストを選択し、[保存]を検索してこれを選択します。
さらに、このアイコンのVisibleプロパティを以下の通り設定します。

If(DataCardValue10.Text=User().FullName && DataCardValue11.Selected.Value="下書き", true, 
  If(DataCardValue15.Text=User().FullName && DataCardValue11.Selected.Value="確認待",true,false)
)

※報告者がアプリユーザーかつステータスが下書きの場合か、マネージャーがアプリユーザーかつステータスが確認待の場合は表示し、その他の場合は非表示とします

アプリを作成する:詳細画面

必要項目の追加(編集画面と同じ)

左側[ツリービュー]の [DetailScreen1>DetailForm1]を選択し、右側[プロパティ]の[ディスプレイ>フィールド]の[8件選択済み]を選択し、[フィールドの追加]を選択します。
[ID]にチェックをつけ、[追加]を選択します。

画面タイトル変更、非表示項目の設定(編集画面と同じ)

項目IDのDataCardValueXXの番号部分(この例では14)を確認の上、画面タイトルを選択し、以下の通り設定します。
・Textプロパティ："執務日報 (ID:" & DataCardValue14.Text & ")"

項目IDの全体領域を選択し、右側プロパティの[ディスプレイ>表示]をオフにしておきます。
これにより、項目IDが編集エリアで非表示になります。

項目のレイアウト調整(編集画面と同じ)

コンテキスト変数の定義(Office365ユーザー情報による条件検索)

マネージャーのEmailアドレスをコンテキスト変数に格納します。この値は確認依頼時にTeamsの通知先として使用します。
左側[ツリービュー]の [DetailScreen1]を選択し、OnVisibleプロパティを以下の通り設定します。

//マネージャーのEmailアドレスを取得(確認依頼フローで使用)
UpdateContext({
  loc_manager_email:LookUp(
    Office365ユーザー.SearchUserV2( {searchTerm:"",
      isSearchTermRequired:false} ).value,
    DisplayName = DataCardValue7.Text
  ).Mail
});

※式の意味：マネージャーの表示名を元にマネージャーのEmailアドレスを取得します

確認依頼・確認処理アイコンの追加・設定

削除アイコンを二回コピー&ペーストして、確認依頼アイコンと確認処理アイコンとして流用します。

追加したアイコンの左側ツリーと右側プロパティの詳細タブにて、下表の通り設定します。

一通り調整すると、以下のようになります。
なお、確認処理アイコンと削除アイコンの位置が重なっていますが、この後、ステータスと役割に応じた表示制御を設定しますので、問題ありません。

左側ツリーにて確認処理アイコン(IconConfirm1)を選択し、[OnSelect]プロパティを以下の通り設定します。

//確認処理(ステータス更新)
Patch(執務日報,
  LookUp(執務日報,ID=Value(DataCardValue14.Text)),
  { status:{Value:“確認済”} }
)

※式の意味：IDをキーにこのデータのステータスを確認済に更新します

左側ツリーにて確認依頼アイコン(IconSubmit1)を選択し、[OnSelect]プロパティを以下の通り設定します。

//確認依頼の処理(ステータス更新、上司へのTeams確認依頼(フロー呼出し))
Patch(執務日報,
  LookUp(執務日報,ID=Value(DataCardValue14.Text)),
  { status:{Value:"確認待"}}
);
UpdateContext({localResponse:執務日報_確認依頼通知.Run(
  loc_manager_email /* manager's email */, DataCardValue1.Text /* working_day */,
  DataCardValue2.Text /* reporter */, DataCardValue4.Text /* tasks */,
  If(IsBlank(DataCardValue5.Text)," ",DataCardValue5.Text) /* good_points */,
  If(IsBlank(DataCardValue6.Text)," ",DataCardValue6.Text) /* improvement_points */,
  DataCardValue14.Text /* ID */
)});

※式の意味：IDをキーにこのデータのステータスを確認待に更新し、確認依頼通知フローを実行します。なお、入力必須でない良かった点・改善点がブランクの場合、フローが正常に実行されませんので、その場合は半角スペースを入れた文字を渡しています。
ちなみに、この段階ではフローが未作成のためエラーが出ますが、フローについては次の工程で紹介します。

各アイコンの表示制御

最後に、各アイコンのVisibleプロパティにて以下の通り、表示制御を設定します。
・確認処理アイコン(IconConfirm1)：If(DataCardValue7.Text=User().FullName && DataCardValue3.Selected.Value="確認待", true, false)
・確認依頼アイコン(IconSubmit1)：If(DataCardValue2.Text=User().FullName && DataCardValue3.Selected.Value="下書き", true, false)
・削除アイコン(IconDelete1)：If(DataCardValue2.Text=User().FullName && DataCardValue3.Selected.Value="下書き", true, false)
・編集アイコン(IconEdit1)：If(DataCardValue2.Text=User().FullName && DataCardValue3.Selected.Value="下書き", true,
If(DataCardValue7.Text=User().FullName && DataCardValue3.Selected.Value="確認待",true,false)
)
※各式の意味：報告者がアプリユーザーかつステータスが下書きの場合は確認依頼・削除・編集アイコンを表示し、マネージャーがアプリユーザーかつステータスが確認待の場合は確認処理・編集アイコンを表示します

アプリを作成する:確認依頼通知フロー

左端の[・・・]アイコンを選択し、[Power Automate]を選択し、[フローを新規作成する]を選択します。
[+ 最初から作成]を選択します。

先にフロー全体を示します。
PowerAppsアプリから通知に必要なデータを受け取り、それらに基づきTeamsにアダプティブカードを投稿します。アダプティブカードの応答を受け取り、JSONの解析によりマネージャーコメントを取り出し、SharePointリストのマネージャーコメントに反映しています。
また、フロー名は[執務日報_確認依頼通知]としました。

ここから各ステップの設定内容を紹介します。

[Power Apps (V2)]ステップでは、[入力の追加]より前の工程の[確認依頼]アイコンでフロー呼出しを行ったときの引数を定義します。
・電子メール：email
・テキスト：working_day
・テキスト：reporter
・テキスト：tasks
・テキスト：good_points
・テキスト：improvement_points
・数：id

次のステップを追加する前に、 Webブラウザーの別タブからPowerAppsのアプリ一覧画面を開き、執務日報アプリのURLを確認しておきます。
PowerAppsのアプリ一覧画面で対象アプリの三点マークを選択し、[詳細]を選択します。
Webリンクに表示される値が執務日報アプリのURLですので、これをメモ帳等にコピー&ペーストして控えておきます。

[変数を初期化する-power-apps-url]ステップの設定は以下の通りです。
・ステップの種類：[組み込み>変数>変数を初期化する]
・名前：power-apps-url
・種類：文字列
・値：(先ほど控えた執務日報アプリのURLをペーストする)

[変数を初期化する-adaptive-card]ステップの設定は以下の通りです。
・ステップの種類：[組み込み>変数>変数を初期化する]
・名前：adaptive-card
・種類：文字列
・値： (AdaptiveCardのJsonデータ。後述します)
※AdaptiveCardの作成例：Microsoft Teams にアダプティブカードを投稿するフローを作成する - Power Automate | Microsoft Learn

AdaptiveCardの値(Jsonデータ)となるコードを改めて掲載します。

{
  "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
  "type": "AdaptiveCard",
  "version": "1.0",
  "body": [
    {
      "type": "TextBlock",
      "text": "執務日報の確認依頼が届きました",
      "id": "Subject",
      "spacing": "Medium",
      "size": "ExtraLarge",
      "weight": "Bolder",
      "color": "Accent"
    },
    {
      "type": "Container",
      "items": [
        {
          "type": "TextBlock",
          "text": "報告者:@{triggerBody()['text_1']}, 稼働日:@{triggerBody()['text']}",
          "wrap": true
        },
        {
          "type": "TextBlock",
          "text": "■業務内容\n\n@{triggerBody()['text_2']}",
          "wrap": true
        },
        {
          "type": "TextBlock",
          "text": "■良かった点\n\n@{triggerBody()['text_3']}",
          "wrap": true
        },
        {
          "type": "TextBlock",
          "text": "■改善点\n\n@{triggerBody()['text_4']}",
          "wrap": true
        }
      ]
    },
    {
      "type": "Input.Text",
      "placeholder": "報告内容についてコメントがあれば入力",
      "style": "text",
      "isMultiline": true,
      "maxLength": 200,
      "id": "manager-comment"
    }
  ],
  "actions": [
    {
      "type": "Action.Submit",
      "title": "確認済",
      "id": "submit-button"
    },
    {
      "type": "Action.OpenUrl",
      "title": "アプリを開く",
      "url": "@{variables('power-apps-url')}"
    }
  ]
}

以下は補足事項です。

業務内容、良かった点。改善点のテキスト内の\n\nは改行です。\nのみですと機能しません。
[組み込み>データ操作>作成]ステップを使って設定する場合、値の中に改行があるとエラーが発生します。改行せずに記述するか、この例のように[組み込み>変数>変数を初期化する]ステップを使用してください。

[アダプティブカードを投稿して応答を待機する]ステップは以下の通りです。
・ステップの種類：[標準>Microsoft Teams>アダプティブカードを投稿して応答を待機する]
・投稿者：フローボット
・投稿先：フローボットとチャットする
・メッセージ(変数)：adaptive-card
・Recipient(変数)：email
・IsAlert：はい
また、ステップ名のアダプティブとカードの間に半角スペースがありますが、これを忘れずに削除しておきます(後続の[JSON の解析]ステップの式内でこのステップを指定する際、ステップ名に半角スペースが含まれると正しく動作しないため)。

次のステップでJSONの解析を追加する際、フローの実行結果を使うと、コンテンツとスキーマを簡単に設定できます。
フローを実行するため、まずは右上のアイコンからフローを保存しておきます。

Webブラウザーの別タブからPowerAppsのフロー一覧画面を開き、対象フローの実行アイコンを選択します。
右側にポップアップしたパラメーター(フローの一番最初のステップで指定した入力項目)を適宜入力し、[フローの実行]を選択します。
指定したemailのユーザーのTeamsに通知が届いたら、コメントを入力して[確認済]を選択します。

PowerAppsのフロー一覧画面の対象フローを選択し、直近の実行履歴を選択します。

[アダプティブカードを投稿して応答を待機する]ステップの[出力>body]の値をコピーします。

フローの作成画面に戻り、
[JSON の解析]ステップを設定します。
・ステップの種類： [組み込み>データ操作>JSON の解析]
・コンテンツ(式)： body('アダプティブカードを投稿して応答を待機する')
・スキーマ：([サンプルから生成]を選択し、先ほどフローの実行履歴からコピーした値をペーストする)

[項目の更新]ステップは以下の通りです。
・ステップの種類：[標準>SharePoint>項目の更新]
・サイトのアドレス：(執務日報データの格納先であるSharePointリストのあるサイト)
・リスト名：執務日報
・ID(変数)：id
・status Value：確認済
・manager-comment(変数)：manager-comment

右上のアイコンからフローを保存して閉じ、アプリの編集画面に戻ります。

アプリ編集画面右上の[保存]アイコンを選択し、[公開]アイコンを選択します。
[このバージョンの公開]を選択します。
左上の[戻る]を選択し、アプリの編集を終了します。

おわりに

このアプリの作成において、特にポイントになりそうな設定要素を挙げておきます。何かアプリを作成する時の参考になれば幸いです。

Office365ユーザー情報によるマネージャーの特定(一覧画面:AppのFormulaプロパティ)
Office365ユーザー情報による条件検索(詳細画面: DetailScreen1のOnVisibleプロパティ)
フロー呼出し時のブランクパラメータの渡し方(詳細画面:確認依頼アイコンのOnSelectプロパティ)
アダプティブカードの投稿および応答結果に基づくデータ更新(確認依頼通知フロー)

また、この例では応答を待つアダプティブカードを使用しましたが、報告者が多くいるマネージャーですと煩わしいかもしれません。確認済ボタンを無くした応答を待たないアダプティブカードに変更する、一覧画面に一括確認の機能(別の記事で紹介)を設ける(マネージャーが確認する意味がなくなりそうですが・・・)など、運用しながら使いやすい形に改善していけると良いと思います。

つらさを経験しているから乗り越えられる - 本日も乙

2025-03-19T12:09:55+09:00

昨日はさいたまマラソンについて書きました。

blog.jicoman.info

先日の日曜日がワースト天候だと思ってましたが、今日がまさかの大雪で更新されましたねw 今日が大会でなくて本当に良かったです。寒さというよりも道路が滑りやすくなって危険をともないますからね（流石に中止かもしれませんが）。

寒さと雨風で心折られた人も多いはずです。私もネガティブになりかけましたが途中からランナー皆でゴールを目指していくという気持ちが強くなってなんだかんだテンションが上っていきました。

こうした気持ちになれた理由を後から考えてみると、昨年の富士山登山の経験が大きかったかなと思います。
大雨の中での登山で真冬並みの寒さに加えて、荷物がすべてずぶ濡れで着替えもほぼ全滅、さらに高山病による体調不良が重なって、本当に辛かったです。
それと比べると、寒さはあっても荷物と着替えは無事ですし高山病のような頭痛や吐き気、息苦しさもありません。とてもつらい経験をしているから、このぐらいのことではなんてことないなと思ってしまいました。感覚が麻痺している気もしますw

システム要件定義の成果物〜設計へのインプットを作成する - TRACERY Lab.（トレラボ）

2025-03-19T11:30:00+09:00

シリーズ: 要件定義とはそもそも何か

TRACERYプロダクトマネージャーの haru です。

要件定義のゴールは、設計の精度を高めるためのインプットとなる成果物を作成することです。適切な成果物があれば、設計工程での手戻りを減らし、スムーズなシステム開発につながります。

本記事では、システム要件定義の成果物を整理し、設計に活用できる形でまとめます。

開発品目の一覧と機能要件、非機能要件
- 非機能要件
  - IPAの非機能要求グレード
概念モデル
システム構成図
最後に

開発品目の一覧と機能要件、非機能要件

ユースケースとロバストネス図によるシステム要件定義 - TRACERY Lab.（トレラボ）では、ロバストネス図から開発対象の品目と機能要件、非機能要件を抽出しました。

開発品目や機能要件は一覧表にまとめると、開発管理や見積りにも活用できます（非機能要件については後述）。

種類	開発品目	機能要件
画面	売上ダッシュボード画面	・日別の売上推移、商品別売上、地域別売上を表示できる・期間、商品の検索条件を指定できる・システムにログインしているユーザーのみ参照可能・閲覧履歴がシステムに記録される。
API	売上データ抽出*1	・日別に集計した売上データを、検索条件に従って出力する
API	売上レポートPDF出力	・売上ダッシュボード画面の簡易版をPDF形式でダウンロードできる・出力項目は売上ダッシュボード画面の項目とする
バッチ処理	売上データ集計処理	・売上ダッシュボード画面に表示するデータを定期的に作成する

非機能要件

ユースケースとロバストネス図によるシステム要件定義 - TRACERY Lab.（トレラボ）では、以下の非機能要件*2を抽出しました。

画面表示は3秒以内
売上ダッシュボードに表示するデータは1日ごとに最新化される

機能要件は各機能ごとに定義されるのに対し、非機能要件はシステム全体に共通するものとして定義されるのが特徴です。ただし、すべての非機能要件がシステム全体に適用されるわけではありません。

上記の非機能要件は、売上ダッシュボード表示という機能をもとに抽出されたものですが、それがシステム全体に適用されるのか、あるいは特定の機能に限定されるのかを慎重に判断する必要があります。

例えば、応答時間の要件は全システム共通かもしれませんが、データ更新頻度の要件はダッシュボード特有のものかもしれません。こうした点を考慮し、システム全体に適用すべき非機能要件と、特定の機能にのみ適用されるものを明確に分類し、リストアップしましょう。

IPAの非機能要求グレード

システム全体に共通する非機能要件を明らかにしていくには、IPAが提供している非機能要求グレードが有用です。非機能要求グレードは、システムの品質特性を明確にし、適切な要件定義を行うための指針となります。

このグレードでは、性能、可用性、セキュリティ、運用管理などの観点から非機能要件を分類し、それぞれに求められる水準を定めています。

概念モデル

概念モデル（Conceptual Model）は、システム開発において業務の本質的な構造や概念を可視化するためのモデルです。

業務領域の主要な概念（エンティティ）とその関係性を整理し、ステークホルダー間で共通認識を持つために活用されます。

概念モデル

ロバストネス図から抽出したエンティティを整理し、エンティティ間の関係を明確にすることで、概念モデルを構築できます。

ロバストネス図をインプットとして概念モデルを作成する

システム構成図

システム構成図とは、システム全体の構造や各コンポーネントの関係（システムアーキテクチャ）を視覚的に表現した図です。ハードウェア、ソフトウェア、ネットワークなどの要素とその関係性を図示します。

システム構成図を作成するにはさまざまな表記法がありますが、ここではUMLの配置図（Deployment Diagram）*3を使用します（下図）。

システム構成図の例

機能要件と非機能要件を実現するための適切なシステム構成を検討し、その結果をシステム構成図として作成します。

機能要件、非機能要件をインプットとしてシステム構成図を作成する

最後に

下図に、システム要件定義の成果物の関係をまとめました（下図）。

システム要件定義の成果物の関係

システム要件定義の成果物として以下を作成しました。

ユースケース
ロバストネス図
開発品目の一覧、機能要件、非機能要件
システム構成図
概念モデル

これらの成果物を元に、システムやソフトウェアの設計を進めることができます*4。

要件は一度で確定するものではなく、議論を重ねる中で決まっていきます。その際、「要望・要求・要件」と「事業・業務・システム」の観点から整理するとよいでしょう。各観点の詳細については、以下の記事を参照してください。

要望、要求、要件
- 要件定義の重要ポイント〜要望・要求・要件を見極める - TRACERY Lab.（トレラボ）
事業、業務、システム
- 事業・業務・システムの3階層で要件を捉える - TRACERY Lab.（トレラボ）

次回は、システム要件定義で作成した成果物と設計の関係について解説します。

この記事を書いた人

haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

*1:画面からアクセスする内部API（外部システムからのエンドポイントではなく、画面からのみアクセスされるもの）について、前記事のロバストネス図上では「バウンダリ」ではなく「コントロール」として表現されている。筆者としては、内部APIを「コントロール」として扱ってよいと考えている（バウンダリでも良い）。

*2:システムの動作や性能、品質に関する要件のこと。機能要件が「システムが何をするか」に焦点を当てるのに対して、非機能要件は「システムがどのようにそれをするか」に焦点を当てる。セキュリティ、性能、信頼性、可用性、保守性、ユーザビリティ、互換性、移植性、法令遵守などがある。

*3:システムがどのようなハードウェア環境（ノード）で構成され、ソフトウェアコンポーネントがどのように配置（デプロイ、インストール）されるかを視覚的に表現する図。主に、システムの物理的な構成や、ソフトウェアのデプロイメント（展開）を明確にするために使用される。

*4:開発対象のシステムによっては、要件定義で複雑なビジネスロジックやデータの状態遷移を整理し、明確にする必要があります。しかし、これらの説明は複雑になるため、本連載「要件定義とはそもそも何か」では割愛します。

GASでの定期実行タスクの設定方法 - yoko's memo

2025-03-19T07:45:15+09:00

Google Apps Script（GAS）を使って定期実行タスクを設定することで、スプレッドシートの更新やメール送信などの繰り返し作業を自動化することができます。この記事では、GASで定期実行タスクを設定する方法を詳しく解説します。

moun45.hatenablog.com

定期実行タスクの概要

GASの定期実行タスクは、指定した時間間隔でスクリプトを自動的に実行する仕組みです。これを実現するためには「トリガー」を設定します。トリガーには時間主導型、イベント主導型などの種類がありますが、今回は時間主導型トリガーに焦点を当てます。

トリガーの種類

時間主導型トリガーには以下の種類があります。

分単位のトリガー：5分おき、10分おき、15分おき、30分おき
時間単位のトリガー：毎時、2時間おき、4時間おき、6時間おき、8時間おき、12時間おき
日付ベースのトリガー：毎日、特定の曜日、毎月特定の日
特定の日時のトリガー：特定の日時に1回だけ実行

定期実行タスクの設定方法

ここでは、基本的なスクリプトを作成し、これを毎日定期的に実行するトリガーを設定する方法を紹介します。

1. スクリプトを作成する

まず、実行したいスクリプトを作成します。以下は、簡単なログ出力スクリプトの例です。

function logCurrentTime() {
 Logger.log('Current Time: ' + new Date());
}

2. トリガーを設定する

次に、このスクリプトを毎日定期的に実行するためのトリガーを設定します。

スクリプトエディタを開く：
- Google スプレッドシートを開き、ツール > スクリプトエディタを選択します。
トリガーを設定：
- スクリプトエディタで、左側の「時計」アイコン（トリガー）をクリックします。
- トリガーを追加ボタンをクリックします。
- 以下のように設定します。
  - 関数を選択：logCurrentTime
  - イベントの種類を選択：時間主導型
  - 時間ベースのタイマー：日付ベースのタイマー
  - 時刻の指定：毎日
  - 実行時刻：希望する実行時刻を選択（例えば、午前9時）
保存：
- 設定が完了したら、保存をクリックしてトリガーを有効にします。

高度なトリガー設定

より複雑なトリガー設定も可能です。例えば、特定の曜日にのみ実行したり、特定の月にのみ実行することができます。

特定の曜日に実行するトリガー

function createWeeklyTrigger() {
 ScriptApp.newTrigger('logCurrentTime')
 .timeBased()
 .onWeekDay(ScriptApp.WeekDay.MONDAY)
 .atHour(9)
 .create();
}

このスクリプトは、毎週月曜日の午前9時にlogCurrentTime関数を実行するトリガーを作成します。

特定の月にのみ実行するトリガー

特定の月に実行するトリガーは直接設定する方法がないため、スクリプト内で条件分岐を使用して、特定の月にのみ動作するようにします。

function monthlyTask() {
 var month = new Date().getMonth() + 1; // 1月が0なので+1
 if (month === 6) { // 6月にのみ実行
 logCurrentTime();
 }
}

トリガーの管理と削除

設定したトリガーは、スクリプトエディタの「時計」アイコンから管理することができます。不要になったトリガーは削除することが可能です。

トリガーの削除

スクリプトエディタを開く：
- ツール > スクリプトエディタを選択します。
トリガーを管理：
- 左側の「時計」アイコンをクリックします。
トリガーの削除：
- 削除したいトリガーの横にある削除ボタンをクリックします。

まとめ

Google Apps Scriptの定期実行タスクを設定することで、繰り返しの作業を自動化し、業務効率を向上させることができます。トリガーを適切に設定し、実行スクリプトを定期的にメンテナンスすることで、信頼性の高い自動化システムを構築できます。この記事を参考にして、GASを使った自動化に挑戦してみてください。

moun45.hatenablog.com

ケーススタディでしっかり身につく! Google Apps Script超入門

作者:境野高義
技術評論社

Amazon

【UE5】暗号論的に安全な疑似乱数を作りたい！(with OpenSSL) - 九尾空間

2025-03-19T01:33:03+09:00

はじめに

Unreal Engineでゲーム開発しているとき、ふと乱数を使いたくなるときってありますよね。サイコロを振りたいとき、攻撃の成功/失敗判定をしたいとき、ドロップするアイテムを確率で決めたいとき……。挙げていくときりがありません。

大体のケースでは FMath::RandRange() だったり FRandomStream だったりの簡易的な疑似乱数生成器で済むことも多いですが、たまに「暗号論的に安全な」「十分なエントロピーを持つ」乱数を生成したくなることがあります。

例えば、データの暗号化に使う秘密鍵を生成したかったり、OAuth 2.0 PKCEで使う認可コード横取り防止の code_verifier を生成する時などです。こういった時に必要となる乱数は、悪意のある第三者に値を推測されたり操作されては非常にマズいので、暗号論的に安全だと広く認められている方法で生成しなければなりません。

今回は、そんな「きちんとした乱数を使わないとセキュリティ的にマズい」時に使用できる乱数生成方法について解説します。

三行でまとめると

Unreal Engine 5にはOpenSSLがバンドルされているので、それを使いましょう。
#include "openssl/rand.h" して RAND_bytes(unsigned char *buf, int num) を呼び出すだけ。かんたん。
Build.cs に依存関係を追加するのを忘れないようにしましょう。

手順

今回は簡単に検証したかっただけなので、適当なActor (AMyActor) のBeginPlayで生成した乱数をログに書き出すコードを書きました。

1. Build.cs の依存関係に `OpenSSL` を追加。

今回はヘッダファイルで使わないので private dependency に追加します。

<Project Name>.Build.cs

using UnrealBuildTool;

public class MyProject : ModuleRules
{
    public MyProject(ReadOnlyTargetRules Target) : base(Target)
    {
        PCHUsage = PCHUsageMode.UseExplicitOrSharedPCHs;
    
        PublicDependencyModuleNames.AddRange(new string[]
        {
            "Core",
            "CoreUObject",
            "Engine",
            "InputCore",
            "EnhancedInput"
        });

        PrivateDependencyModuleNames.AddRange(new string[]
        {
            "OpenSSL", // ← 追加
        });
    }
}

2. 実装を作成

MyActor.h

UCLASS()
class MYPROJECT_API AMyActor : public AActor
{
    GENERATED_BODY()

    // ... 省略 ...

protected:
    virtual void BeginPlay() override;

private:
    /// <summary>
    /// InLengthで指定したバイト数の暗号学的に安全な乱数を生成します。
    /// 生成した乱数はBASE64でエンコードし、OutStringに格納して返します。
    /// </summary>
    /// <param name="InLength">生成する乱数のバイト数</param>
    /// <param name="OutString">生成した乱数列を格納する先のバッファ</param>
    /// <returns>生成に成功したらtrue, 失敗したらfalse</returns>
    static bool GenerateRandomBase64(uint32 InLength, FString& OutString);
};

MyActor.cpp

// OpenSSLをインクルード。
// 定義しておかないとエラーになるマクロがあるので定義しておく。
#define UI UI_ST
THIRD_PARTY_INCLUDES_START
#include "openssl/rand.h"
THIRD_PARTY_INCLUDES_END
#undef UI

void AMyActor::BeginPlay()
{
    Super::BeginPlay();

    FString RandomString;
    if (!GenerateRandomBase64(32, RandomString))
    {
        // 乱数生成失敗
        UE_LOG(LogTemp, Error, TEXT("Failed to generate random string"));
    }
    else
    {
        // 乱数生成に成功したのでログに出力
        UE_LOG(LogTemp, Display, TEXT("Random string is: %s"), *RandomString);
    }
}

bool AMyActor::GenerateRandomBase64(uint32 InLength, FString& OutString)
{
    // 乱数データを書き出すためのバッファを確保
    TArray<uint8> RandData;
    RandData.SetNumUninitialized(InLength);

    // 乱数生成。成功したら 1 が、失敗ならそれ以外の値(0 or -1)が返ってくる。
    if (RAND_bytes(RandData.GetData(), InLength) != 1)
    {
        // 失敗したのでfalse。
        return false;
    }

    // BASE64エンコード
    OutString = FBase64::Encode(RandData);
    return true;
}

3. 動作確認

AMyActorをレベル上に配置し、PIEのプレイボタンを押して実行。

ちゃんと生成されていそう

ここで1点だけ注意。私の環境だけかもしれないのですが、Unreal エディタ右下のコンパイルボタンからビルドしようとするとOpenSSLのリンク周りで沢山のエラーが出ました。一度Unrealエディタを落として、Visual Studio側からリビルドをかけたら正常に動作するようになりましたので、もしうまく動かないようであればそちらを試していただければと。

「未解決の外部シンボル」エラーが沢山出ている

まとめ

以上の手順で、Unreal Engineで暗号論的に安全な方法で乱数を生成することができます。外部のAPIを叩くなどの目的で安全な疑似乱数生成器をお探しだった方は、是非この方法を試してみてはいかがでしょうか。

また、ゲーム内でUnreal Engine標準の疑似乱数生成器の出力では満たせない、高品質で推測が困難な疑似乱数をお探しだった方にとっても、ここで紹介した手法が役に立つかもしれません。

とはいったものの、暗号学的に安全ということはそれなりに高コストな実装になっているはずですし、あまり濫用してしまうと疑似乱数生成器の出力から内部状態を類推する攻撃等を受けるリスクもあります。あまり濫用しすぎるのは控えたほうがいいかもしれません……。RAND_bytes() は本来、Unreal Engine内部でSSL通信するため等の用途で使っているはずなので、攻撃されるとマズいです。

是非ともOpenSSL公式のドキュメントをご確認の上、用法用量を正しく守ってお使いください。

docs.openssl.org

それはともかく、OpenSSLは暗号通信用ライブラリなので、疑似乱数生成器以外にもいろいろ使えそうな関数が沢山ありそうです。特に、APIで外とやりとりしようとする時には、HMACを生成できる関数などは非常に役に立つのではないでしょうか。

今回の記事で示したとおり、依存関係の設定さえしてしまえばUnreal EngineのC++から普通にOpenSSLの関数が呼べます。皆様も是非、使えそうなOpenSSLの関数を探して試しに使って見てはいかがでしょうか。

先行研究その1。暗号学的に安全な疑似乱数の生成やHMACの計算はサーバー側で行っているようだ。

mizuame.works

先行研究その2。OpenSSLの関数をUnreal EngineのC++から呼ぶ方法。

qiita.com

Unreal EngineのC++からOpenSSLの関数を呼ぶ方法について、Unreal Engineの公式フォーラムのスレッド。

forums.unrealengine.com

Udemy：C#を勉強する順番を受講した - walog

2025-03-18T21:57:00+09:00

こちらの講座を修了したので、講座の内容と感想を書く。 www.udemy.com

概要

タイトルそのまま、C#を勉強する順番を1時間程度で解説している動画。

の順に勉強することを推奨し、その理由を教えてくれている。

感想

私はC#歴が長いのだが、その割には「プログラミングができる！」という手ごたえがあまり無く、現在も迷走している。そんな中でながら見しつつ視聴した。文法、コーディングルール、オブジェクト指向は新卒のころから嫌になるほどやっている。 TDDも職場で一応それらしきものをやっている。ちょっとエセだけど。ドメイン駆動開発、デザインパターン、リファクタリングは今の私の関心を寄せる内容であり、同時に本やネットの記事を読もうとしても中々読めていないもの達だ。

今の自分の現在地を確認し、次のステップを目指そうという気持ちにしてくれる良い動画だと思った。今は手を動かしたい時期なので、次は同作者の「C#でドメイン駆動開発」シリーズを進めてみようと思う。

回復環境が見つかりません対処法　その２ - 佐々木屋

2025-03-17T19:20:28+09:00

以前Windows回復環境で以下の話をしました。
sasaki816.hatenablog.com

一応これで回復環境は復活するのですが、別の問題で回復環境が使えない場合があります。
WinRE を有効にするコマンド「reagentc /enable」をしても「REAGENTC.EXE: Windows RE イメージは見つかりませんでした。」というエラーが表示される場合が今回の現象です。

reagentc /enable
REAGENTC.EXE: Windows RE イメージは見つかりませんでした。

この原因はWinre.wim（Windows RE イメージ）が起動できない場合です。この場合はWindows10又は11のISOファイルからWinre.wimを取り出して入れてしまえば解決します。

Windows 11 のダウンロード
www.microsoft.com

リンクを開いたら、インストールメディアを作成するところまで行って「今すぐダウンロード」を選択します。

ダウンロードした実行ファイルを実行して、適当な外付けUSBにインストールメディアを作成してください。
* なお、作成対象にしたUSBは全てフォーマットされますので注意！

作成が終わったら、作成したインストールメディアを開いて、「sources」→「install.esd」を右クリック→「7_Zipで開く」で開きます（7_Zipは自力でインストールしてください・・・）。

こんな感じで格納されているので、

自分のパソコンのエディションを選択します。
1 = Windows 10 Home
3 = Windows 10 Pro

「Windows」→「System32」→「Recovery」に「Winre.wim」があるので、これを回復環境を復活させたい対象パソコンの「C:\Windows\System32\Recovery」へコピーします。

次に対象パソコン側で、以下コマンドを発行します。

reagentc /setreimage /path C:\windows\system32\recovery

「REAGENTC.EXE: 操作は成功しました。」と表示されればＯＫ。

もう一度、以下を実行します。

reagentc /enable

「REAGENTC.EXE: 操作は成功しました。」と表示されれば成功です。

これでめでたく回復環境が使えるようになります。

工数と工期を見積もる：プロジェクトマネジメントの個人的なコツ - yug1224's diary

2025-03-17T12:05:06+09:00

プロジェクトマネジメントについて、個人的なコツをまとめてみた。とくに、工数や工期の見積もりについての考え方を中心に書いている。

「不確実性コーン」を意識した工数見積もり

時間やストーリーポイントなど、まずは何かしら工数を見積ると思うが、その際は「不確実性コーン」を意識することを心掛ける。

プロジェクトのスコープ、ステークホルダー、要求事項、リスクなど、プロジェクト進行に必要な情報は、プロジェクト開始時には明確になっていないことも多いため、見積もりの振れ幅は大きくなる傾向がある。プロジェクトを検討し始めた時は、0.25倍〜4.0倍の振れ幅があり、プロジェクトの工程が進むにつれて、この振れ幅は小さくなる。この特徴をグラフで表したものが「不確実性コーン」である。

xtech.nikkei.com

工数の見積もりをする際には、プロジェクトの現在地を考え、感覚値でも良いので最大の振れ幅も考慮しておく。また、現在地が移動した際には、新たに明らかになったり確定した情報が増えているはず。なので、工程やタスクの切れ目では、後続タスクの見直しを行い、スケジュールを常に最新の状態に保つことが重要だと思う。

工数以外の「変数」を考慮した工期見積もり

工数が見積もれたら、次は「可処分時間」「バッファ」「営業日」などを意識しながら工期を考える。

この工期見積もりでよくありがちな失敗として、n時間の工数を単純に8で割った数を必要日数としてしまい、余裕のないギチギチのスケジュールになってしまうことがある。現実的な工期見積もりを実施するために、工数とは別の変数も合わせて考えると良い。

MTGや他作業の時間を抜いて開発に充てられる 「1日の可処分時間」
工数見積もりの振れ幅・正確さ・信頼度で考慮した 「バッファ係数」（たとえば、プロジェクト初期や信頼度が低い場合は1.5、プロジェクト後期や信頼度が高い場合は1.2などと置く）
プロジェクト期間内の休日やメンバーの有給取得日を考慮した 「営業日」

これらの変数を用いて 「（必要総工数 × バッファ係数）÷ 1日あたりの可処分時間 = 必要日数」 を計算する。たとえば、合計100時間を見積もった場合は「（100h x 1.5）÷ 4h = 37.5d」のように計算ができ、ここからさらに営業日を考慮して、最終的な工期を見積もることができる。

バッファの掛け方については、人は資源をあればあるだけ使ってしまうという 「パーキンソンの法則」 もあるので、「CCPM（クリティカルチェーン・プロジェクトマネジメント）」 などの手法を用いて、タスクバッファではなくプロジェクトバッファとして管理するのが良いかなと思う。

ja.wikipedia.org

www.diamond.co.jp

まとめ

プロジェクトマネジメントは、さまざまな要素を考慮しながら進める必要があるが、「不確実性コーン」「可処分時間」「バッファ」などを意識しながら、揺れを最小化するような工夫をしていくことが大事だと思う。また、プロジェクトマネジメントだけでなく、日常生活や仕事全般にも応用できると思うので、参考にしてもらえたら嬉しい。

単体テストの考え方/使い方 - ram memo

2025-03-16T14:26:44+09:00

### メモ

プロダクションコードも、テストコードも、資産ではなく負債として見るべき

優れたテストスイートの特徴

- テストすることが開発サイクルの中に組み込まれている

- 最小限の保守コストで最大限の価値を生み出すようになっている

単体テストの定義

- 1単位の振る舞いを検証すること

- 1単位のコード（class等）ではない

- 実行時間が短いこと

- 他のテストケースから隔離された状態で実行されること

単体テストではないものは、統合（integration）テスト

- E2Eは統合テストの一種

- 共有依存

- テストケース間で共有される依存

- プライベート依存

- 共有されていない依存

- プロセス外依存

- アプリケーションを実行するプロセスの外で稼働する依存

- プロセスのメモリ上にないもの

依存

- 共有依存

- プライベート依存

- 可変依存

- 不変依存（値オブジェクト。単に「値」とも言う）

協力者オブジェクト

- 共有依存

- 可変依存

古典学派では、共有依存のみをテストダブルに置き換える

- ロンドン学派は不変依存を除く全ての依存をテストダブルに置き換える

AAAパターンにおける実行フェーズに記述するコードが1行を超す場合、APIの設計が不十分な可能性がある

- 1単位の振る舞いで適切に手続きが行われるようカプセル化されていない可能性

- これがない場合、不変条件の侵害が発生し得る

良い単体テストを構成する4本の柱

- 退行（regression）に対する保護

- バグを見つけ出す能力

- 以下が基準となる

- テスト時に実行されるプロダクションコードの量

- そのコードの複雑さ

- そのコードが扱っているドメインの重要性

- リファクタリングへの耐性

- テストコードがテスト対象のコードの詳細と結びつくと発生する

- 壊れやすいテスト

- 実装の詳細ではなく、最終的な結果を確認する

- 迅速なフィードバック

- テストが遅いと得られない

- 保守のしやすさ

- テストケースを理解することがどれくらい難しいのか？

- テストを行うことがどれくらい難しいのか？

- テストを行うのにプロセス外依存を必要とする場合、手間がかかる

以下のどれか2つしか満たせない。

- リファクタリングへの耐性

- 退行に対する保護

- 迅速なフィードバック

かつ、リファクタリングへの耐性を犠牲にすることはできないため、

退行に対する保護と迅速なフィードバックの間でバランスを調整することとなる

（リファクタリングへの耐性は1か0かしかないため）

テストダブル

- モック（外部へ向かうコミュニケーション（出力）を模倣、検証する）

- モック

- モックフレームワークの力を借りたもの

- スパイ

- 開発者自身で実装されるもの

- スタブ（内部へ向かうコミュニケーション（入力）を模倣する）

- スタブ

- ダミー

- nullや適当な文字列等のシンプルな値

- フェイク

モックの検証は行うが、スタブの検証は行ってはならない

- 観察可能な振る舞い

- クライアントが目標を達成するために使う公開された操作、状態

- 実装の詳細

- 上記以外

カプセル化

- 不変条件の侵害からコードを守るための手段

- 実装の詳細を隠す

時間とともにコードは複雑になる

- 間違ったことをする可能性を取り除くようつとめる

- ソフトウェアの持続可能な成長

ヘキサゴナル・アーキテクチャ

- ドメイン層

- ビジネスロジック

- アプリケーション・サービス層

- ドメイン層と外部アプリケーションとの連携の指揮

関心の分離

単体テストの3つの手法

- 出力値ベースのテスト

- 状態ベースのテスト

- コミュニケーションベースのテスト

出力値ベースのテストが最も優れている

関数型プログラミング

- 純粋関数を用いたプログライミング

- 全ての入力と出力がメソッドシグネチャ（メソッド名、引数、戻り値）で構成される

- 隠れた入力や出力を持たない

- 何度呼び出しても同じ結果となる

関数型アーキテクチャ

- 副作用をビジネスオペレーションの最初や最後に配置することで、ビジネスロジックと副作用を分離しやすくする

- ヘキサゴナルアーキテクチャはドメイン層で副作用を起こしてもドメイン層内で制限されている限り問題ないが、関数型アーキテクチャは全ての副作用をドメイン層の外に出す

決定と指揮を分離する

- 関数的核

- 決定を下す

- 可変核

- 関数的核に入力を提供したり、決定に基づいて副作用を起こす処理を行う

プロダクションコードの種類

- ドメインモデル／アルゴリズム

- コードが複雑orドメインにおいて重要だが、協力者オブジェクトは少ない

- 取るに足らないコード

- コードが複雑でもなく、ドメインにおいて重要でもなく、協力者オブジェクトも少ない

- コントローラ

- このコードだけで複雑なことやビジネス的に重要なことを行うことはないが、複数のコンポーネントが適切に連携できるような調整を行う

- コードが複雑でもなく、ドメインにおいて重要でもないが、協力者オブジェクトは多い

- 過度に複雑なコード

- 複雑さやドメインにおける重要性が高く、協力者オブジェクトも多い

ドメインモデルは単体テストし、コントローラは統合テストする

「過度に複雑なコード」を、ドメインモデルとコントローラに分離する

- 質素なオブジェクトパターンを用いる

質素なオブジェクトパターン

- 簡単にテストできない依存を結びついてしまったコードは、テストに手間がかかる

- プロセス外依存等

- 過度に複雑なコードからロジックを抽出する

- 抽出されたロジックはテストを難しくする依存から切り離される

- 抽出されたロジックを包み込む質素なクラスを作成し、質素なクラスに対してストが難しい依存を結びつける

- 質素なクラスにはロジックをほぼ含ませず、テストする必要ないようにする

以下を分離するのが重要

- ビジネスロジックに関するコード

- コードの深さ（複雑さ、重要性）

- コードの複雑は決定を下す分岐の数によって判断できる。循環的複雑度

- 連携の指揮に関するコード

- コードの広さ（協力者オブジェクトの数）

深さと広さの両方を持ったコードを作ってはならない

確認後実行（CanExecute/Execute）パターン

- コントローラがより複雑になっていくことへの対策

- ドメインイベントの利用

「ビジネスロジックに関するコード」と「連携の指揮に関するコード」を分離する場合のバランス

- ドメインモデルのテストのしやすさ

- 協力者オブジェクトの数と種類に影響される

- コントローラの簡潔さ

- コントローラの決定を下す箇所（分岐）の数に影響される

- パフォーマンスの高さ

- プロセス外依存への呼び出しを行う回数に影響される

コントローラの簡潔さより、ドメインモデルのテストのしやすさやパフォーマンスの高さを優先する

- コントローラがより複雑になっていくことへの対策

- 確認後実行（CanExecute/Execute）パターン

- ドメインイベントの利用

- 単体テストはビジネスシナリオにおける異常ケースをできるだけ多く検証する

- 統合テストは1件の最長のハッピーパスと単体テストでは検証できない全ての異常ケースを検証する

- 最長のハッピーパスは全てのプロセス外依存を経由してビジネスシナリオを正常に終わらせる実行経路

テストスイート全体の保守コストを少なく保つ

管理下にあるプロセス外依存はモックせず、管理下になりプロセス外依存をモックする

- 前者はデータベース、後者はメールサービスやメッセージバス等

- プロセス外依存にはインターフェースを持たせる

YAGNI原則

- 現時点で必要でない機能について時間を費やすべきではない

- 将来的に追加される機能を予想して開発したり、既存のコードを修正したりするべきではない

- 現時点では必要ない機能を念の為に導入することは、コードベースの所有に対するコストを不必要に費やす

- コード量は少ないほど良い

全ての依存は、常に、コンストラクタやメソッドの引数を経由して明示的に注入されるべき

抽象化の欠落

- プライベートなメソッドがあまりにも複雑で、公開されているAPIからプライベートなメソッドを十分に検証することが難しいのであれば、テスト対象のコードに対する抽象化が欠落している可能性がある

- 抽象化できる部分を別のクラスとして抽出した方がいい

- Orderクラスのプライベートクラスで複雑な価格計算をするのではなく、PriceCalculatorというクラスに分ける

# 参考

book.mynavi.jp

Goのソースコードを解析して、依存しているOpenTelemetry Semantic ConventionsのAttributeを洗い出すツールを作りました - Diary of a Perpetual Student

2025-03-16T12:02:10+09:00

モチベーション

Go言語でできたアプリケーションにOpenTelemetryの手動計装を行う際、Semantic Conventionsに定められたAttributeを付与するため、OpenTelemetry Go SDKのsemconv packageに定義されている定数や関数を参照してコードを書くことがあります。例えば、以下の例ではResourceに対してservice.name属性を付与しています。

import semconv "go.opentelemetry.io/otel/semconv/v1.31.0"

resource.New(ctx, resource.WithAttributes(semconv.ServiceName("myService")))

ここまで読んでサッパリ何のことがわからない場合には、残念ながらこのエントリを興味深く読めないかもしれないです。

さて、Semantic Conventionsで定められた慣例というのはバージョンを追うごとに変化していきます。例えば、データベースのクエリを表すdb.statementという属性は、v1.25.0からdb.query.textにリネームされました*1。

自分たちの計装が古いSemantic Conventionsに定められた属性に依存していないか、依存していたら新しい名称にリネームできないかというのは興味の対象になります。

semconview-go

今回、semconview-goというCLIツールを開発しリリースしました。

github.com

Goのソースコードを静的解析することで、semconv.ServiceName("myService")やsemconv.ServiceNameKeyなどといった、semconv packageの呼び出しを記録し、これをattributeのkey名に変換してリストアップするものです。

将来的には、リネームされ非推奨になった属性を教えてくれるような機能を追加したり、属性だけでなくメトリック名にも対応することを目指しています。

Homebrewでのインストールができたり、コンテナイメージも配布していたりしますので、ぜひご利用ください。

実装

semconv packageの定数・関数の呼び出し

まず、Goのソースコードの各ファイルごとimport文を解析し、importしているOpenTelemetry Go SDKのsemconv packageのパスとローカル変数名との対応を取ります。

import (
    semconv127 "go.opentelemetry.io/otel/semconv/v1.27.0"
    semconv "go.opentelemetry.io/otel/semconv/v1.31.0"
)

というコードであれば、semconv127→go.opentelemetry.io/otel/semconv/v1.27.0、semconv→go.opentelemetry.io/otel/semconv/v1.31.0という対応表を作る、というイメージです。

internal/semconview/analyzer.go#L122-L139

semconv packageの定数・関数名をAttributeキーに変換する表の作成

次に、importしているsemconv packageの中身を解析し、定数名や関数名をAttributeキーに変換する表を作っていきます。Go packageの解析にはgolang.org/x/tools/go/packagesを使用できます。

以下のようなコードでpackageをロードします。

internal/semconview/semconvpkg.go#L82-L103

次に、attribute.Key型の定数を探します。

const (
    ServiceNameKey = attribute.Key("service.name")
)

のようなコードになっているので、attribute.Keyの型変換が右辺にあるような代入式を探し、Keyの引数を取り出すことで、定数名と属性キー名の対応表を作ることができます。

/internal/semconview/semconvpkg.go#L105-L164

最後に、attribute.KeyValue型を返却する関数を探します。

func ServiceName(val string) attribute.KeyValue {
    return ServiceNameKey.String(val)
}

のようなコードになっていて、return文の中には先ほど検出対象としたattribute.Key型の定数が含まれています。先ほど作った、定数名と属性キー名の対応表を活用することで、関数名と属性キー名の対応表も作ることができます。

internal/semconview/semconvpkg.go#L166-L206

semconv packageからの呼び出しを検出して属性キーに変換

ここまで来ればあと少しです。元のGoのソースコードを解析し、importして利用しているsemconvの定数や変数を検出します。そして、先ほど作った表を用いて属性キーに変換します。

internal/semconview/analyzer.go#L141-L197

余談

今回、目的を達成するツールを作りたいというほかに、2つのチャレンジをしていました。

Goのコードを静的解析する方法を身につける
生成AIエージェントの支援を得てコーディングする

仕事であんまりコードを書かなくなりつつあるので、ちょっとした余暇でものづくりをする際にいろんな目論見を一回の挑戦に詰め込みがちになっています。

*1:https://github.com/open-telemetry/semantic-conventions/blob/6533b8a39e03e6925e080d5ca39234035cf87e70/schema-next.yaml#L241-L244

Google スプレッドシートから一括で CSV でダウンロードするpythonスクリプト - Buri Memo:

2025-03-15T13:25:07+09:00

ゲームのシナリオをスプシ管理したくなった。でも1個ずつダウンロードするのはめんどくさいので自動化してみた。

必要なもの

python3
gspread
GCP の認証情報
ダウンロード元の Google スプレッドシートの ID

認証情報はこちらの記事の手順で作成できる。

Google SpreadSheetのデータを Pythonで取得する #GoogleCloud - Qiita

スプレッドシートのIDはURLから持ってくる。

https://docs.google.com/spreadsheets/d/{  スプレッドシートのID  }/edit

ダウンロードするシートをタイトルで絞り込める。例えば TARGET_SHEET_TO_DOWNLOAD = r"C[0-9]{3}_S[0-9]{3}" 設定することで画像の「シート2」を除外してダウンロードする。

ソースコード

$ pip install gspread

import gspread
import re
import csv
from concurrent.futures import ThreadPoolExecutor
import time

CREDENTIALS_PATH = "GCP クレデンシャルの JSON ファイルのパス"
SPREDSHEET_ID = "スプレッドシートURLから ID 部分を取ってくる"
OUTPUT_PATH = "出力先のパス"
TARGET_SHEET_TO_DOWNLOAD = r".*"

gc = gspread.service_account(filename=CREDENTIALS_PATH)

sh = gc.open_by_key(SPREDSHEET_ID)

def download(sheet):
    print(f"Downloading {sheet.title}...")
    with open(f"{OUTPUT_PATH}\{sheet.title}.csv", "w", -1, "utf-8") as f:
        writer = csv.writer(f)
        writer.writerows(sheet.get_all_values())
    time.sleep(1)

# 1秒間に送信するリクエスト数は worker 数で制御する
tpe = ThreadPoolExecutor(max_workers=10)

for sheet in sh.worksheets():
    if not re.match(TARGET_SHEET_TO_DOWNLOAD, sheet.title):
        continue
    
    tpe.submit(download, sheet)

tpe.shutdown()

論文解説「MORF: A Post Mortem」 - くろみーの日報テンプレ

2025-03-15T10:00:00+09:00

大学院で教育工学を専攻していた時の名残で、今でも Learning & Engineering というメーリングリストに登録しているのだが、先日コミュニティでこんな論文が話題になっていた。

https://dl.acm.org/doi/10.1145/3706468.3706478

タイトルは「MORF: A Post Mortem」。著者はペンシルベニア大学の Ryan Baker 氏と Denver 大学の Stephen Hutt 氏だ。自分の研究分野では有名な LAK（Learning Analytics and Knowledge）というカンファレンスで発表された論文。公開が 3 月 3 日と書いてあるからかなり最近の論文だ。

まず目を引くのはタイトルにつけられている "A Post Motem" というフレーズである。ポストモーテムといえば、何がしかのインシデント（トラブル）への検証や分析を指すが、自分が知る限りでは、あまり論文で好んで使われる単語ではないように思う。

というのも、あるプロジェクトのポストモーテムを書くということは、暗にそのプロジェクトが失敗だったと認めることになり、これは公的な資金を投入して行われた研究プロジェクトにとっては、あまり好ましいことではない。

なんでわざわざポストモーテムというタイトルとつけたのか気になって、自分の仕事とは関係ないのだがせっかくなのでちょっと読んでみることにした。

MORF とは

MORF とは The MOOC Replication Framework の略で、直訳すると MOOC のレプリケーションを行うためのフレームワークということになる。

MOOC のレプリケーションってなんぞやと思うかもしれないが、このフレームワークが生まれた背景には、Coursera や edX をはじめとする、大規模で無料のオンラインコース（Massive Open Online Course）が急速に普及し、多くのユーザーを獲得した経緯があった。

こうした大規模なオンラインコースには、多くの学習者によって蓄積された大量のデータがあり、これは学習者の行動や学習成果に関する貴重な情報源となる一方で、個人のプライバシーにも関わるセンシティブな情報である。

この問題を解決すべく生まれたのが MORF であり、要するに学習者のプライバシーを守ることを最優先におき、研究者が安全に大規模なデータセットを分析できるような MOOC のレプリカを提供するためのフレームワークということになる。

MORF の詳細については2018 年に発表された論文があるので、興味がある方はそちらを参照してほしい。GitHub に公式のレポジトリも公開されている。

github.com

なぜ失敗したのか

MORF の失敗要因はいくつか挙げられているが、自分が興味を持ったポイントについてかいつまんで説明してみる。

まずは Docker コンテナの問題。MORF はユーザーがどの言語を用いて分析しても問題ないように、ユーザーに自身の解析スクリプトを Docker コンテナとしてアップロードさせる仕組みを採用していたのだが、どうもこれが研究者にとっては技術的なハードルが高すぎたらしい。

これは自分も経験があるのだが、研究者の中にもいろいろなタイプがあり、Python や R で分析用の高度なスクリプトを書ける人が必ずしも Docker の基礎的な技術を身につけているかというとそうではない。特に Web 系の技術に疎い研究者にとっては Docker という言葉自体がなんなのかわからないという人も多い。そんな中で、分析用のスクリプトを Docker コンテナに詰め込むというのは MORF のユーザーである分析系の研究者にとってはかなりハードルが高い作業と言える。筆者らもこの点について、言語を問わないという意味で間口を広げたつもりが帰ってユーザーを限定する結果になってしまったと述べている。

次にデバッグと出力の問題。MORF では学習者のプライバシーを守るため、デバッグ用のエラーメッセージにも最小限の情報しか返さないようにしていたという。また分析結果についてもあらかじめ MORF 側で定義されたフォーマット以外の出力は表示されないようになっていたらしく、これも分析者の自由度を狭める結果となった。前者については上述した Docker の問題とも相まって、慣れない Docker を使うにあたってかなり MORF を使用するハードルを上げてしまっていたのではないかと思われる。

ポストモーテムの意義

このようにこの論文では MORF という分析フレームワークが広まらなかった要因として幾つかの課題が挙げられているが、そもそもなぜこのポストモーテムが必要だったのだろうか。

私はおそらく MORF のような課題は、教育工学分野の内外を問わず、多くの研究者が抱えている課題なのではないか、と思う。今回の件をより一般化していうと、フレームワークや研究の理念を優先させすぎると、ユーザー体験を損ない、結果として誰も使わないプロジェクトになってしまうということだ。

いくら崇高な理念に基づいたプロジェクトであっても、誰からも必要とされないものができてしまっては本末転倒である。

今回の論文でもネクストアクションとして、ユーザービリティテストの強化やコミュニティの育成が挙げられていた。プロジェクト（研究）の本質ではない部分で、よりユーザーに近いウェットな部分にも焦点を当てることが重要であるということだ。

近年プロダクト開発における PM (プロダクトマネージャー) という役割が注目されているが、技術や理念だけではない部分の重要性をこの論文からあらためて学べた気がする。

【初心者向け】基板って何？— 基本のキから解説！ - 電子部品と一緒に成長！新米エンジニアの学びメモ

2025-03-13T23:37:10+09:00

社会人になってすぐ「基板交換してみようか！」と言われ、何もわからないまま「はい！」と返事した新米エンジニアです。

「基板って実際にどんなもの？」について今回は解説していきたいと思います。

電子機器の中を開けると、緑色の板にたくさんの電子部品がくっついているのを見たことがあるかもしれません。これが「プリント基板（PCB）」です！

スマートフォン、パソコン、テレビ、家電…ほとんどの電子機器に使われている、とても重要な部品です。

今回は、「そもそも基板とは何なのか？」という基本から、役割やプリント基板の特徴について初心者向けにわかりやすく解説していきます！

1. 基板とは？電子機器の心臓部分！

基板は、電子部品を固定し、電気的につなぐための土台です。

もし基板がなかったら、電子部品同士を 1本1本手作業で配線しなければならず、機器をコンパクトに作ることができません。

例えば、スマホの中には小さな基板が入っています。

基板には、電気を流すための道（回路パターン）がプリントされており、電子部品が適切に接続されています。これによって、スマホのような複雑な電子機器もコンパクトにまとめることができるのです！

2. プリント基板（PCB）って？

基板にはいくつか種類がありますが、一般的な電子機器で使われるのは「プリント基板（PCB: Printed Circuit Board）」です。

✅ ユニバーサル基板（ブレッドボード）との違い

初心者が電子工作をするときによく使うのが、ユニバーサル基板やブレッドボードです。

基板の種類	特徴	例
ブレッドボード	配線を自由に変更できる（実験用）	電子工作、試作回路
ユニバーサル基板	ハンダ付けして配線する	自作回路、小型ロボット
プリント基板（PCB）	配線があらかじめ印刷されている	スマホ、パソコン、家電

プリント基板は「プリント」という名前の通り、銅の回路パターンが板の上に印刷されているのが特徴です。

これによって、ミスなく、コンパクトに、効率よく配線することができます！

3. なぜ基板が必要なのか？（配線と比較して解説）

昔の電子機器では、部品同士を手作業で1本1本配線していました。

しかし、この方法には問題点があります。

❌ 手作業の配線のデメリット

1. 配線が複雑になりすぎる → 回路がぐちゃぐちゃ

2. 人が配線するのでミスが多い → 接触不良が起こる

3. 大量生産が難しい → 1台作るのに時間がかかる

そこで登場したのがプリント基板（PCB）です！

✅ プリント基板のメリット

• 配線をあらかじめ印刷できる → 自動で配線OK！

• 同じものを大量に作れる → コストを下げられる

• コンパクトにできる → スマホやノートPCに必須！

例えば、スマホの中には何百もの部品が詰まっていますが、すべてプリント基板の上にコンパクトに配置されています。

もし昔のように 1本1本手作業で配線していたら、今のスマホのサイズでは作れません！

まとめ：基板の基本をおさらい！

✅ 基板とは？ → 電子部品を固定し、電気的につなぐための土台

✅ プリント基板（PCB）とは？ → 銅の配線が印刷された基板

✅ なぜ基板が必要？ → ミスなく、コンパクトに、大量生産できるから！

エンジニアグループ

FreeCAD 熱解析ガイド⑥ 複合材料の温度シミュレーション精度を検証 - 個人的にCAE...

GoogleのGemini大幅アップデート：AIの画像生成能力が新次元へ - エンジニアの思い立ったが吉日

AIモデルの訓練で時給4500円、米国の「大卒副業ワーカー」が直面する現実 - 元スマホエンジニアのニュース雑記

M/M/1の印刷時間を計算 - SLnavkのブログ

問題

爆速解法

じっくり解説

【体験談】半年間のキャリアコーチングを走りきって得られたもの - Halcyon Days

なぜキャリアコーチングを受けようと思ったか

キャリアコーチングとは？

どのキャリアコーチングサービスを選んだか

サービスの選び方

私が選択したサービス

キャリアコーチングを通して得られたもの

現時点での理想のゴール

決めきる大切さ

行動

キャリアコーチングを受けてみて

リスク中心の脅威モデリング手法！TRIKEとは？DFDを活用した分析を解説 - 城咲子｜情シスセキュリティ担当のつぶやき（ぼやき）

TRIKEとは？

TRIKEの主な特徴

TRIKEのプロセス

TRIKEの利点

まとめ

VPC、サブネット、セキュリティグループの違い - プログラミング学習サイト

VPCとは何か?

VPCのIaCコードサンプル

AWS Subnet

SubnetのIaC

サブネットのCIDRの決め方

AWSルートテーブルとAWSルート

AWSのルートテーブル、ルートのIaCコード

AWS InternetGateway

AWS NetworkACL

パブリックなNetwork ACLの例

プライベートなNetworkAClの例

ネットワークACLのIaCコードの例

セキュリティグループ

HTTP/HTTPSサーバー向けのセキュリティグループ

サブネットに合わせるケース

test

VPCのメリットとは何か?

VPCで最も大事なのがCIDRブロック

具体的なイメージ例1

備考

PowerApps マネージャー確認機能付き 執務日報アプリ２ - 情シス仕事の備忘録

アプリを作成する:編集画面

必要項目の追加、コントロールの種類変更

画面タイトル変更、非表示項目の設定

項目のレイアウト調整

各項目の設定(表示モード、入力必須、初期値)

保存アイコンの設定変更

アプリを作成する:詳細画面

必要項目の追加(編集画面と同じ)

画面タイトル変更、非表示項目の設定(編集画面と同じ)

項目のレイアウト調整(編集画面と同じ)

コンテキスト変数の定義(Office365ユーザー情報による条件検索)

確認依頼・確認処理アイコンの追加・設定

各アイコンの表示制御

アプリを作成する:確認依頼通知フロー

おわりに

つらさを経験しているから乗り越えられる - 本日も乙

システム要件定義の成果物〜設計へのインプットを作成する - TRACERY Lab.（トレラボ）

開発品目の一覧と機能要件、非機能要件

非機能要件

IPAの非機能要求グレード

概念モデル

システム構成図

最後に

GASでの定期実行タスクの設定方法 - yoko's memo

定期実行タスクの概要

トリガーの種類

定期実行タスクの設定方法

1. スクリプトを作成する

2. トリガーを設定する

高度なトリガー設定

特定の曜日に実行するトリガー

特定の月にのみ実行するトリガー

トリガーの管理と削除

PowerApps マネージャー確認機能付き執務日報アプリ２ - 情シス仕事の備忘録

1. Build.cs の依存関係に `OpenSSL` を追加。

Udemy：C#を勉強する順番を受講した - walog

回復環境が見つかりません対処法　その２ - 佐々木屋