OmniAICreator/Qiita-1.07M huggingface dataset:
環境内のデスクトップフロー数を取得する方法について

※ この記事は、[Microsoft Power Automate Advent Calendar 2024](https://qiita.com/advent-calendar/2024/powerautomate) 12月16日 担当分の記事です。

# 環境内のクラウドフロー数を取得する

環境内のクラウドフローの数を取得するのであれば、Power Automate管理コネクタの「管理者としてフローの一覧を取得 (V2)」を利用することで可能です。

![desktopflow_count01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1382111/af6e2630-377b-8555-2d10-7b870a9fff3b.png)

以前に記事を書いたのでこちらをご参照ください。
[作成されたクラウドフロー数をカウントする](https://tana-techlog.net/?p=1377)

しかし、デスクトップフローの場合は、該当するアクションが存在しないので、ほかの手段をとる必要があります。

# 環境内のデスクトップフローの数を取得する

デスクトップフローの数を確認する方法については、以前に記事を書いたのでこちらもご参照ください。
[テナント全体のデスクトップフローの確認方法](https://tana-techlog.net/?p=122)

以前の記事では、手動で確認しに行く方法を記載していました。
今回は、クラウドフローを利用して、自動的に取得する方法について記載したいと思います。
なお、システムカスタマイザーやシステム管理者のセキュリティロールが付与されている必要があります。

[組織アカウントを利用した場合のPower Automate for desktopで作成したデスクトップフローの落とし穴](https://tana-techlog.net/?p=91) の記事でも触れていますが、デスクトップフローの情報は、Dataverseのテーブルに保存されています。

Dataverseのテーブルに保存されているのであれば、Dataverseコネクタを利用して取得が可能ということになります。

:::note
Dataverse コネクタは、プレミアムコネクタですので、Power Automate Premiumなどのライセンスが必要となりますので、ご注意ください。
:::

Dataverseコネクタの「選択した環境の行を一覧表示する」アクションで該当テーブルの情報を取得できます。
![desktopflow_count02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1382111/669dd88c-d10f-9f40-17ba-22b2c4bcb916.png)

アクションの設定は以下のようになります。
![desktopflow_count03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1382111/79bbf4ae-b8eb-aee4-1ff7-0eea88cf5237.png)

① 「環境」で取得したい環境を選択します。

② 「テーブル名」にデスクトップフローの情報が保存されているテーブルを指定します。
具体的には、「Workflow」テーブルに保存されています。
日本語環境の場合、アクションの「テーブル名」の選択肢では、表示名が「プロセス」となっているので注意が必要です。

③ 「列を選択する」では、「Workflow」テーブルから必要な列の内部名を指定していきます。
今回は、フローの名前とフローの種類を判別するために、'name'と'category'をカンマ（,）区切りで記載します。

④ 「行のフィルター」には、以下のように記載します。
'category'列に「6」という値が入っているものが、デスクトップフローに該当します。

~~~
category eq 6
~~~

あとは、「選択した環境の行を一覧表示する」アクションの出力結果を、length() 関数で数をカウントすればOKです。


以前に、[まっぴぃ](https://x.com/mappie_kochi) さんが、「[Power Automate for desktop が Dataverse 容量を勝手に消費する話](https://zenn.dev/ymasaoka/articles/how-pa-for-desktop-consumes-dataverse-capacity)」で、PowerShellで取得する方法を記載してくださっています。
こちらも同じように'category'列に「6」となっているレコードを抽出しています。
ご参考まで。


# 最後に

システムテーブルとして、最初から作成されている Dataverseのテーブルについては、以下のように公式ドキュメントに内容が掲載されています。

[Process (Workflow) テーブル/エンティティの参照 (Microsoft Dataverse) - Power Apps | Microsoft Learn](https://learn.microsoft.com/ja-jp/power-apps/developer/data-platform/reference/entities/workflow?WT.mc_id=DX-MVP-5005072)

読み取るのはなかなか難しいですが、Dataverseテーブルから情報を取得するという方法もあるというのを知っていただければと思い、本記事を書きました。

試行錯誤が必要ですが、それも面白さのひとつかなと思います。
ぜひ、Power Automate Lifeを楽しんでいただければと思います。
仮想環境でゲームがしたいarchプレイヤーが希望を残して敗北した忘備録

# 経緯
仮想環境でゲームがしたくなりました。
基本Archlinuxを使っているのですが、ゲームをするならwindowsしか勝たないんですよね。
でもデュアルブートで交互に使うのは不便だなー
という考えから仮想環境でゲームをしようと考えたわけです。
なぜwindowsの方でArchの仮想環境を立てないのかというとArchの設定を引っ越すのが面倒だからです。

# 結果
結論できなかったのですが、一縷の望みを残します。
**vGPU-unlock**という**サードパーティー**製の技術があるのですが、Proxmoxが公式にサポートしているようでした。
Proxmoxはサーバー管理ができるOSでVMの作成ができます。
ただ、メインPCにProxmoxを入れるのは気が引けてしまったので、今回はこれからの技術の発展を期待することにしました。

やっていることは平凡ですが、その結論にたどり着くまでの記録を書きます。

## 何をしたのか
Archlinux上にOracleVMからwindowsに接続します。

まずはvirtualboxをインストール
```
sudo pacman -S virtualbox
```
VertualBoxの説明と初期設定の話をしていると長くなってしまうので割愛します。

windows11 [ISO](https://www.microsoft.com/ja-jp/software-download/windows11)


### 3Dアクセラレーション

VMの設定>ディスプレイ>3Dアクセラレーション
の項目をチェックするとできます。
一応ビデオメモリーを256MGにします。

Vboxがシャットダウンの状態じゃないと設定が変更できないのに少しハマりました。

### Guest Additions
起動したVMのスクリーン上部にあるバーのデバイスの一番下から挿入を行う。
ファイルからVBoxWindowsAdditions.exeを実行する。(場合によっては管理者権限で)

### ディスクの処理が重い
[参考サイト](https://jp.minitool.com/data-recovery/fix-windows-11-high-disk-usage.html)
上記のサイトからSuperfetchを無効にしました。

以上

## VertualBoxの理由
もとよりKVMを使うことで仮想環境を行おうと考えていました。
KVMはカーネルに直接組み込む形の仮想環境でVertualBoxよりもパフォーマンスが良いです。
少しでもコストを抑えたかったのでKVMを選択していました。
(単純に大規模サーバー向けのKVMを触りたかったというのもある)

## vGPU GPUパススルーって何？
しかし、元の目的としてのゲームを行うことを忘れていてKVMではvGPUとGPUパススルーでしかグラボ接続する方法がない問題に当たりました。
vGPUは**特別**な物理GPUのリソースを分割をすることができます。
GPUパススルーはGPUの接続をゲストOSにすることでGPUを使う(ホストOSではGPUが使えない)。

そのため3Dアクセラレーションが利用できるVertualBoxを利用することにしました。
3DアクセラレーションではホストOSのグラフィックボードを借りて動かすことができます。
[詳しくはdocで](https://www.virtualbox.org/manual/topics/guestadditions.html#guestadd-3d)


# おまけ
特別な目的がない限りVirtualBox一択になるでしょう

しかし、
CPUのリソースを食い尽くしてゲームはまともに動作しませんでした。
軽いゲームなら動きます。
いつかlinuxでwindowsゲームができる日が来ることを祈ります。

**間違いなどがあれば指摘していただけると助かります。**

終わり
OpenAI、新ビデオ生成ツール「Sora」をローンチ！動画の世界にAIが殴り込み

「12 Days of OpenAI」3日目の発表は、**Sora** という待望のビデオ生成サービス。  
前回までは o1 や Reinforcement Fine-Tuning といった高性能なテキストモデルの話題でしたが、今回は一気に映像の世界へと踏み込んできました。「ついに来たか！」と思わず身を乗り出してしまいました。

この記事は[ChatGPT Advent Calendar 2024](https://qiita.com/advent-calendar/2024/chatgpt)の8日目です（空いていたので書いてみました）今年は「12 Days of OpenAI」ということで毎日発表がありましたが、その内容を復習しながらまとめます

## Sora って何？
Sora は **テキストや画像、あるいは複数の場面を並べた“ストーリーボード”** から、驚くほど自然な動画を作り出すプラットフォームです。これまでもいくつかのAIツールが映像生成を試みてはいましたが、OpenAI が本格的に手がけるのは今回が初。今回リリースされた “**Sora Turbo**” は、今年の初めに「世界シミュレーション（World Simulation）」という形で一部公開されていたモデルを高速化＆軽量化したものだそうで、ユーザーが簡単に使える製品レベルに仕上がっているのがポイント。

### なにが嬉しいのか
1. **テキストだけじゃない、映像の時代**  
   文字ベースの AI だけでは表現しきれないものを、動画生成で補える。創作者にとっては新しいツールが手に入るワクワク感がある。  

2. **単なる投稿サイトではなく「作って共有する場」**  
   Sora には **“Explore”** というフィードが用意されていて、みんなが作った動画を観賞できるだけでなく、どうやって作ったか（テキストやストーリーボードなどの手順）までも追える。気になった動画があれば、自分で「Remix（リミックス）」機能を使ってアレンジできるのが斬新。  

3. **ChatGPT Plus／Pro で使える**  
   既存の ChatGPTユーザー（Plus や Pro）なら追加料金なしで Sora が使える。  
   - **Plus ユーザー**: 月50回の生成が可能  
   - **Pro ユーザー**: “Slow Queue” というやや遅めの生成は無制限、速い通常生成は月500回まで。  
   動画生成のクオリティや長さ、解像度などで必要な計算量も変わるので、自分にあった形で使い分けるイメージですね。

## 実際の使い方をざっくり紹介
動画ではいくつものデモが披露されていて、観ているだけでもかなり楽しい。ざっくりどういう操作をするのか整理してみます。

### Library と Explore
- **Library**: 自分がこれまでに作成した動画や下書きの管理画面。グリッド表示やフォルダ分けができるので、複数のプロジェクトを同時に進めるときでも便利そう。  
- **Explore**: コミュニティの作品を流し見できるフィード。「その作品はどんな手法で生成されたか？」がカード形式で示されるので、自分でも真似しやすい。  

### シンプルな動画生成
Library から “Composer” というテキスト入力欄へ行き、 **「曖昧なイメージやシチュエーションを文章化」** してリクエストする。たとえば「砂漠を歩くマンモス」なんて入力すると、Sora が数秒から数十秒で複数パターンの5～20秒動画を吐き出してくる。  
このとき解像度（480p～1080p）やアスペクト比、動画の本数を指定可能。ひとつだけでなく4パターン同時生成もできるのが嬉しい。

### Remix／Recut／Loop／Blend — 豊富なエディット機能
- **Remix**: 作成した動画の内容をテキストで変更する機能。たとえば「マンモスをロボットに置き換えて」と指示すると、本当にマンモスがロボットに変身する。  
- **Recut**: 既存の動画を時間軸でトリミングしたり、前後をストーリーボードで補足したりして継ぎ足す。  
- **Loop**: 動画の冒頭と結末をつないで永遠にループ再生するための機能。繋ぎ目が自然になるように補完フレームを挿入してくれる。  
- **Blend**: 2つの動画を“ミックス”して、新たなスタイルに落とし込む不思議な機能。例として「マンモス動画 + ロボット動画」をブレンドさせれば、どんなカオスな映像になるかは想像するだけでニヤニヤしてしまう。

### Storyboard（ストーリーボード）
今回の目玉機能の一つ。**時間軸をいくつかに区切って、場面や動きをテキストで指示**できる。  
たとえば「鶴が立っている → 5秒後に水中から魚をくわえる」みたいな感じにシーンを並べていくと、その通りの動画を生成してくれる。部分的に画像をアップして「ここからシームレスに動画化」なんて使い方も可能。  
正直、初見では「これで映画が作れるのでは…？」と思ったが、開発陣いわく「そこまで大規模な動画はまだ無理」とのこと。でも将来的にはもっと長尺にも対応していきそうな予感がします。

## 対応地域や注意点
- **対応地域**: アメリカや多くの国で同時ローンチ。ただし、**欧州やイギリスでは未対応**で、具体的な解禁時期は未定とのこと。  
- **利用プラン**: ChatGPT Plus なら月50回、Pro ならもっとたくさん。解像度次第で“高コスト”になる場合もあるので、うまくやりくりしよう。  
- **安全性**: やはり映像生成となると肖像権や誹謗中傷など、いろいろな問題が出やすい。OpenAI側もモデレーションにはかなり気を使っているようで、リリース時点で厳しめに制限している部分もある模様。ユーザーからのフィードバックを受けて逐次調整していくようです。

## 個人的な感想
個人的に刺さったのは「**Remix**」と「**Storyboard**」。どちらも **“完成映像の後からシーンを変える”** みたいな機能で、普通の動画編集ソフトだとあり得ない体験。  
Remix であっさりキャラを差し替えられるのは、もはやゲームか映画の “神の視点” みたいで胸が踊るし、Storyboard のタイムライン式 UI は、もはや「文章＋タイムライン」の設計が標準になるんじゃないかと思うくらいにしっくり来ました。

これがローンチ直後のバージョンで、今後まだまだ発展するというのだから恐ろしい。マルチモーダルAIの「1つの完成形」が、段々と見えてきた気がします。  
ヨーロッパを含む対応外の地域もいずれは使えるようになるはずなので、気になる方は続報を要チェックですね。

---

**参考動画**: [Sora–12 Days of OpenAI: Day 3 - YouTube](https://www.youtube.com/watch?v=2jKVx2vyZOY)
laravel 結局キューとジョブとワーカーってなんなの

## 概要

laravelのキューとジョブとワーカーについて簡単にまとめる。

## 内容

### キュー

処理を入れておくための「筒」
この「筒」の素材（ドライバ）を指定する事ができる
素材（ドライバ）の種類は下記

- sync（ローカル開発環境のみの設定を推奨。動作確認には使えるが同期処理になってしまうのでデプロイしたら「挙動が変わった」なんてことがありうる。）
- database
- redis
- beanstalkd
- sqs

どの素材（ドライバ）を使うかは自由だがそれぞれ得手不得手がある。（マイグレーションが必要だったり、デプロイ時に別途お金がかかったり。ローカル開発環境だけでも別でDockerコンテナ立てる必要があったり）

### ジョブ

実行する処理命令が記載されているもの
基本的に非同期実行したい処理をただ書くだけ。
若干お作法があるので注意

### ワーカー

キューに入ったジョブの処理を実行してくれるもの
本当にそれだけ。

## キューとジョブとワーカーの使い方（ローカル開発環境でターミナル使用）

1. .envの`QUEUE_CONNECTION`を確認し、必要の応じてキューの素材（ドライバ）をdatabaseなどに変更
1. DBにjobsテーブルがあることを確認（なければ`$ php artisan make:queue-table`を実行してから`$ php artisan migrate`を実行）
1. ジェネレートコマンド（`php artisan make`）を使ってジョブを作成
1. 作成されたジョブのファイルに処理を記載
1. tinkerやコードで`ジョブのクラス::dispatch();`を実行しジョブをキューにいれる
1. ターミナルで`$ php artisan queue:work`を実行しワーカーを起動

## 参考文献

https://readouble.com/laravel/11.x/ja/queues.html
2因子間網羅の種類に関して

## はじめに
組合せテストの用語がいくつかあり、個人的に混乱していたので
自分の備忘録として雑に残したいと思います。

## 前提
2因子間の組合せとそれ以外の因子を網羅することによって、全網羅テスト実施時不具合のの70%以上を検出できる結果

## どんな用語がある？
- 2因子間網羅
- 直行表
- ペアワイズ法
- ALL Pairs法

## 各々がどんなものか整理する
- 2因子間網羅
    - 任意の２つの因子の全組合せを網羅するテスト設計手法の手法
    - 全体の概念で、以下3つは2因子間網羅の手法の種類
- 直行表
    - 因子間の組合せを効率的に設計する方法
    - 直行表は統計学で用いられる手法で、必ずしも網羅されない場合がある
- ペアワイズ法
    - すべての因子間のペアを最低1回網羅する
- ALL Pairs法
    - ペアワイズ法と同義として使われる場合がほとんど

|項目|2因子間網羅|ペアワイズ法|ALL Pairs法|直行表|
|---|---|---|---|---|
|定義|全体の概念|手法|手法|手法|
|目的|効率的な網羅|最小ケースでの網羅|全ペアを完全網羅|高い網羅性を目指す|
|範囲|2因子間を定義|2因子間を網羅|2因子間を網羅|必要に応じて高い網羅|

## こんな感じ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2987894/5b3a486d-232d-d51d-c4d5-cbe58c5ef547.png)


## その他
簡単にペアワイズ法での組合せを作成するには**PictMaster**というツールがあります。
検索すればすぐに使い方など見つかると思うので、ぜひ使ってみてください。
AWS Managed Microsoft ADやActive Directoryを利用する際の名前解決の選択肢と注意点

# はじめに
AWS Directory Seriviceや、Active DirectoryをVPC内で利用するケースにおける名前解決のポイントをまとめます。

# AWS Managed Microsoft ADとは
AWSが提供するフルマネージド型ディレクトリサービスで、クラウド環境やオンプレミス環境でアプリケーションやサービスに統合できるディレクトリ機能を提供するサービスです。
Microsoft Active Directoryをマネージドに利用でき、ユーザ認証など様々なユースケース二利用されます。

# VPC上の名前解決
通常、VPC上での名前解決では、Route53 Resolverが担当します。
これは、DHCPオプションセットで定義されており、デフォルトでRoute53Resolver（AmazonDNS）がDHCPでDNSの向き先として指定されます。
DHCPオプションセットの書き換えにより、任意のDNSを指定することが可能ですが、様々なケースにおいて、接続先となるマネージドサービス（VPC Endpoint,RDS,DyanamoDB,S3など）の名前解決が必須であるため、注意が必要です。

https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/DHCPOptionSetConcepts.html

![スクリーンショット 2024-12-22 13.52.31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/584167/9c741085-6d97-d3da-3f9a-00841d9d8e48.png)

# ADを利用する場合の問題点
ADを構築しただけでは、ADへの名前解決ならびに、AD自身が持つDNSを利用することはできません。
そのため、ADに参加したい、ADに接続したいと思って、ADのFQDNを叩いても、Route53Resolverは宛先IPを返してあげることができないのです。

![スクリーンショット 2024-12-22 13.57.26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/584167/51613a59-86b7-0604-367b-9e1732a4fa9c.png)

# 解決策
解決策としては以下２つが考えられます。

- DHCPオプションセットでデフォルトのDNSの向きさきを変更する
- Route53 Resolver Outbound Endpointにより、条件付きの名前解決の転送ルールを設定する

細かく見ていきましょう

## DHCPオプションセットの書き換え
![スクリーンショット 2024-12-22 14.05.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/584167/955a41d4-c8a2-b803-7b77-383cbfea5de0.png)
このパターンでは、DHCPオプションセットを書き換え、DNSの向きさきをADにしてしまいます。
これにより、AD内の名前解決は問題なく実施できます。また、AD内では名前解決ができないものに関してはフォワーダをRoute53Resolverに設定することで名前解決が可能です。

注意事項として、名前解決の全てをADを経由するため以下に気をつける必要があります。
- VPC内のインスタンスすべてのDNSの向き先を変えてしまう
ADと関係ないリソースに関してもADに対しての名前解決が可能になり、すべての名前解決をAD経由で実施することになります。

- 名前解決の可用性、性能がADに依存する
ADは、VPC上にENIを伸ばし、ENIから接続を受け付けます。
１ENIあたり、最大65000までの接続上限となるため、名前解決が大量に行われるケースでは、性能制約があります。また、ADを経由するため、AD自体が障害を起こす場合、AD以外の名前解決もできず、他サービスへの接続もできなくなる可能性があります。（AZ構成などにも依存）また、ADを経由することで、クエリパフォーマンスにも影響する可能性があります。

## Route53 Resolver Outbound Endpointの利用
![スクリーンショット 2024-12-22 14.18.09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/584167/34ffa5b9-675f-30a3-e8d3-af54aa3fcce2.png)

この構成ではDHCPオプションセットの書き換えは行いません。Route53ResolverOutbound Endpointを構築し、ResolverルールでADで解決したいドメインに関する転送設定を付与します。これにより、ADのDNSに関する名前解決のみをADで実施することが可能です。そのため、ADの可用性や性能に依存せず、AD以外の名前解決が実施可能です。

注意事項として、Outbound Endpointを構築することで以下に気をつける必要があります。
- コスト
Outbound Endpointのコストが追加でかかります。
ENI毎に決して安いとは言えないコストがかかりますので、注意です。
AZが３つあれば、３つ分かかります。

https://aws.amazon.com/jp/route53/pricing/

- 可用性
AZが複数ある場合は、AZ毎に作らないと可用性が低下します。

# まとめ
以下、まとめです。
AWSを利用する場合は、名前解決に注意が必要です。
また、名前解決に限りませんが、何かを経由することはその部分の可用性、性能がボトルネックになる可能性があるということを覚えておく必要があります。何を取るのか次第でたいていの選択はトレードオフとなるのです。注意して構成を検討しましょう。

|案  |メリット  |デメリット  |
|---|---|---|
|DHCPオプションセット  |コストが安い、設定がシンプル  |性能、可用性がAD依存となる、AD以外の名前解決もADを経由する  |
|Route53 Resolver Outbound Endpoint  |AD以外の名前解決は通常通りのルートで実施可能、ADの性能、可用性に依存しない  |Outbound Endpointのコストがかかる  |
ぷよを分類したい！(3 / 2) 棋譜化(理論)編

# この記事について
この記事は [某企業アドベントカレンダー2024](https://adventar.org/calendars/10291) の22日目の記事で、[9日目の記事](https://qiita.com/takamu_destroy/items/cde4c97fef595fe60bbc) の続きとなります。

---

# 前回までのあらすじ
ぷよの色認識をする機械学習モデルを作成しました。このモデルに赤色のぷよ画像を渡すと、赤のラベル (`R`) を返してくれます。

<div align="center">
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1061119/13d2c75f-852b-75cc-6495-34b3ddd254b1.png" alt="色認識モデルの画面" width="70%">
</div>

---

# 本記事でやりたいこと
そもそも色認識のモデルを作成した理由はなんでしたっけ？  
そう、 **ぷよぷよのプレイ動画から棋譜を作成したい** のでした。本記事では、動画からテキストへ変換する手法を探ります。

---

# 棋譜化とは

棋譜化とは、ゲームや競技の進行を記録し、「棋譜」という形式にまとめることです。目的は主に以下の2つです：

### 1. **保存**
   名勝負や重要な対局を後世に残すため。  
   - 例: 歴史的な一戦を記録し、共有する。

### 2. **学習**
   過去の対局を振り返り、良い手・悪い手を分析するため。  
   - 例: 自分や他人の戦略を研究する。

---

### 棋譜化に適した条件
棋譜化はどの競技でも可能なわけではありません。以下の条件を満たしていると適しています：

1. **状態が明確に表現できる**  
   - プレイの進行が具体的で記録しやすい。  
     例: 将棋の「△3四歩」や囲碁の「D16」。

2. **ターン制である**  
   - プレイヤーが順番に行動し、それぞれの手が独立している。  
     例: チェスやオセロなど、手番が明確な競技。

---

### 棋譜化が難しい競技の例
状態が複雑で連続的な競技では棋譜化が難しくなります：

- **サッカーやバスケットボール**  
  選手の動きやプレイがリアルタイムで変化するため、テキスト形式での記録は現実的ではありません。

- **FPSやMOBAなどのeスポーツ**  
  瞬時のアクションや膨大なデータ量をテキストで表現するのは困難なため、リプレイや動画形式が主流です。

---

# ぷよぷよの棋譜化

ぷよぷよは棋譜化に適しています。以下の理由から、囲碁や将棋のように棋譜が作成可能です：

- 縦12マス、横6マスの盤面に対して、1ターンに2個ずつぷよを配置するルールが、「状態の明確さ」と「ターン制」の条件を満たしている。
- 棋譜による学習が期待できる。

---

### 動画保存の課題
現在、ぷよぷよのプレイ学習には YouTube などの動画が利用されていますが、動画は容量が非常に大きいため、将来的に保存しきれない可能性があります。  
テキスト形式で保存できれば、容量の問題を大幅に解決できます。

それでは、「ぷよ譜」を作成するための準備を整えていきましょう。

---

# ぷよ譜に必要な情報

:::note info
今回は問題を簡単にするため、一人プレイの棋譜化を前提にします。
:::

### 座標系の説明
ぷよぷよ盤面の座標系は以下の通りです：

- 縦は `a~m` のアルファベット
- 横は `1~6` の数字

例えば、1手目で緑を `1a`、赤を `1b` に配置した場合、「1aG1bR」と記録します。  
2手目以降も同様に表記し、カンマ区切りでテキストへ変換します。

<div align="center">
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1061119/01351e9d-b501-e765-918f-41fef0231eae.png" alt="色認識モデルの画面" width="25%">
</div>

<div align="center">
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1061119/e910fd0f-40d7-d2b0-0c2a-7a896c0d849f.png" alt="ぷよ譜例" width="70%">
</div>

---

# 有効フレームの決定

有効フレームとは、N手目の盤面として判断するにふさわしい動画フレームを指します。

プレイ動画には複数のフレームが含まれており、その中から有効フレームを判定する必要があります。例えば、以下のような中間フレームも含まれるため、どれが有効なのかを機械的に判断するルールが求められます。

<div align="center">
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1061119/2f526573-1117-c276-ec05-6da941fcd31d.png" alt="中間フレーム例" width="70%">
</div>

---

# 結言

次回の記事では、この問題の解決方法を含め、実際に動画から棋譜化までのプロセスを解説します！ ~~ネクストコナンズヒント~！~~

**「ネクスト・ネクネク」**  

それではまた来年〜(?????)
安全確保支援士　暗記事項まとめ　【認証とアクセスコントロール】

情報処理安全確保支援士の暗記する必要のあるもののまとめ。自身の勉強ログです。
随時更新していきます。

# IAM関連知識
## IAMとは
識別・認証された利用者が許可されている権限内で利用できるように制御するコントロールシステム
### 識別
アクセスする主体を見分けること
### 認証
正当な利用者であることを検証すること
### 認可
利用者に特定の権限を与える
### アカウンティング
利用者のアクセスログを記録
## AAAフレームワーク
アクセスコントロールに必要となる構成要素（RFC2904）
認証・認可・アカウンティングの頭文字

# 認証
## IEEE802.1X
PCをLANポート接続しただけではネットワークに参加できなくする仕組み。
3つのコンポーネントで構成される
1. サプリカント：認証を受けるクライアント。EAPを使って認証情報を送信する。
1. 認証装置（オーセンティケータ）：サプリカントと認証サーバの間
1. 認証サーバ（RADIUS）：認証するサーバ

## EAP
認証プロセスを実行する際に使用されるフレームワーク
|フレームワーク名  |クライアント認証  |サーバ認証  |
|---|---|---|
|EAP-TLS  |デジタル証明  |デジタル証明  |
|EAP-TTLS  |ID/PASS  |デジタル証明  |

## FIDO認証
パスワードの安全な運用が限界としてパスワードの依存を軽減した認証方式。通称パスワードレス認証。公開鍵暗号方式にて運用。
以下の3つの仕様が公開されている
1. U2F
パスワードとUSBキーの二要素認証
1. UAF
FIDO対応の認証器（スマホ）を使った認証デバイスで生体認証
1. FIDO2
UAFとU2Fを統合

# 推奨されるパスワードの設定・運用・管理方法（過去に出題実績が有るもの）
## 設定方法
* 推測しやすい文字は使用しない
* 初期パスワードを発行する場合、ランダムで意味のないものとする
* 二要素認証
## 運用方法
* 秘密に管理。メモは作らない
* アカウントロック
* 一定期間ログインに成功していないときログイン不可能にする（サスペンド状態）
* パスワードを共有・共用・貸与しない
* 定期的に変更
* 初期パスは確実な本人確認の実施
## 管理方法
* 利用者が自分のパスワードを管理
* ハッシュ関数＋ソルトを用いて暗号化

# 認可
## アクセス権付与の原則
* 責務の分離の原則
複数のサブジェクトに権限を分離。担当の後上司が承認することと同義
* 最小権限の原則
言葉のまま。必要最低限の権限にしようねってこと
## アクセスコントロールの種類
* 任意アクセス制御（DAC）：自分の所有するリソースに自分でアクセスできる
* 強制アクセス制御（MAC）：特定の管理者によってセットされる。セキュリティポリシに基づき設定
* ロールベースアクセス制御（RBAC）：権限を役割別に付与
# シングルサインオン
## エージェント方式
アクセス対象を各サーバにエージェントをインストール
## リバースプロキシ方式
端末はリバースプロキシにアクセス。リバースプロキシを通じて各サーバにアクセス
## 代理認証方式
端末はプロキシサーバにアクセスし、プロキシサーバがユーザ名とパスワードを各サーバに送信
Cloud Run × Cloud Build Next.jsをCloud Runにデプロイするときの備忘録

## はじめに
Next.jsで作成したWebアプリケーションをGoogle Cloudのインフラを活用してデプロイする際、**Cloud Build**と**Cloud Run**を組み合わせることで、効率的でスケーラブルな環境を構築できます。本記事では、その手順を備忘録としてまとめました。

---

## Cloud Buildとは
**Cloud Build**は、Google Cloudが提供するCI/CDツールです。コードのビルド、テスト、コンテナ化、デプロイなどのプロセスを自動化できます。

[Cloud Build 公式](https://cloud.google.com/build)

---

## Cloud Runとは
**Cloud Run**は、Google Cloudが提供する完全マネージドなコンテナ実行環境です。
Cloud Buildと組み合わせることで簡単にwebアプリをデプロイできます。
デフォルトでhttpsのURLも付いてくる優れ物！
[Cloud Run 公式](https://cloud.google.com/run)

---

## 前提
この記事では、Google Cloud上での手順に焦点を当てています。そのため、以下を前提とします：
- GitHubのリポジトリにNext.jsプロジェクトが用意されている。
- DockerfileがNext.jsプロジェクト内に配置されている。

---

## Google Cloudのセットアップ

### 1. 使用するAPIの有効化
Google Cloudプロジェクトを作成し、以下のAPIを有効化します：
- **Cloud Build API**

### 2. Cloud Runのリポジトリ接続設定
Cloud Runの管理画面から「リポジトリを接続」を選択します。

### 3. サービス作成画面でCloud Buildの設定
サービス作成画面で「Cloud Buildの設定」に進みます。

![サービス作成画面](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1289475/50385635-9b8f-d83f-26e6-0ab1c58051f5.png)

### 4. リポジトリとブランチの設定
Next.jsプロジェクトが含まれるリポジトリ、対象ブランチ、およびDockerfileのパスを入力します。

> **注意**: GitHubとGoogle Cloudの連携が未設定の場合は、GitHubの「Integrations/Applications」からGoogle Cloudとの連携を設定してください。

### 5. サービス名とリージョンの入力
適切な「サービス名」と「リージョン」を設定します。

### 6. 認証の設定
「未認証の呼び出しを許可」を選択します。今回はNext.jsで公開することを想定してこの設定を使用します。

### 7. 作成
設定が完了したら「作成」をクリックします。しばらく待つと、Cloud Runのサービス画面に表示されるURLからデプロイ済みアプリケーションを確認できます。

## 環境変数の利用
環境変数を利用する場合は、以下の手順を追加で行います。

### 8. Dockerfileに環境変数の設定を追加
以下のように`ARG`と`ENV`をDockerfileに記述します：
```dockerfile
ARG _API_URL
ENV API_URL=$_API_URL
```
### 9. Cloud Buildトリガーを編集
対象のCloud Buildトリガーを開きます。

### 10. Cloud Build構成ファイルの編集
構成エディタを開き、以下の変更を加えます。
![CloudBuild構成](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1289475/692deca3-0d3e-4c3b-4f38-e39fcf1d2f3c.png)

Buildコマンドに``--build-arg``を追加
```yaml
  - name: gcr.io/cloud-builders/docker
    args:
      - build
      - '--no-cache'
      - '--build-arg'
      - '_API_URL=${_API_URL}'
      - '-t'
      - >-
        $_AR_HOSTNAME/$PROJECT_ID/cloud-run-source-deploy/$REPO_NAME/$_SERVICE_NAME:$COMMIT_SHA
      - .
      - '-f'
      - [Dockerfileパス]
    id: Build
```
``substitutions``に環境変数を追加
```yaml
  _API_URL: [バックエンドAPIサーバーURL]
```
### 11. 保存と実行
編集内容を保存し、Cloud Buildトリガー画面から「実行」または、対象ブランチにpushして再度CI/CDプロセスを実行します。

これにより、環境変数が反映されたWebアプリがデプロイされます。

## 終わりに
この記事では、Cloud BuildとCloud Runを活用したNext.jsアプリのデプロイ手順を解説しました。
インフラ周りの設定は最初の構築時以降あまり触れないことが多いため、備忘録として記録しておくと便利です。
これを機に効率的な運用を目指し、知識を定着させていきたいと思います。
米田の補題 #4 圏の定義①　対象と射

# 米田の補題は、圏論でもっとも重要な定理です（繰り返し）
圏論は、数学の基礎理論です。いままで、[万物の理論](https://amzn.to/3ZLmCJH)
といわれていましたが、[数理科学 11月号](https://amzn.to/4iz6NgM)では、なんと　<font color="Red">万物・万事・万人</font>のための数学理論とまでいわれるようになりました
このAdventCalendar は、体験的に圏論の最も重要な定理である米田の補題を体験的に理解してもらうためにかいています

参考にしているのは、[圏論の道案内](https://amzn.to/4iH2Rus)です

# 米田の補題 #4 圏の定義①　対象と射
米田の補題を理解するには、通常なら圏、関手、自然変換と理解していく必要があります。まともにやったらかなり時間がかかります。そこでかなり端折った説明をするわけですけれども、いくらなんでも少しはそれらしい数学的な説明をおこないます。まず、圏の定義　対象と射です。一つの射を選ぶとそれは域という対象から余域という対象に矢印が伸びているものです。域、余域のかわりに、はじめ、つぎを使ったほうがわかりやすいですけど、慣習上そうなっているので仕方ないです。射は、対象の域、余域が一体になっています。射を選ぶと、特定の域と余域を選んだことになります

```mermaid
graph LR;
    域-.->|射|余域;
    はじめ-.->|射|つぎ;
```

# 射の例
対象ふたつ、矢印ひとつの例が最初はよく挙げられます
```mermaid
graph LR;
    A1[前]-.->|物事|B1[次];
    A2[原因]-.->|因果関係|B2[結果];
    A3[東京]-.->|移動|B3[大阪];
    A4[犬]-.->|含まれる|B4[哺乳類];
    A5[私]-.->|伝える|B5[相手];
```

## 米田の補題川柳　物事は前から次があるものだ
この定義を川柳にしてみました。いくらでも川柳はつくれますが、万物の理論っぽいのを作りました。
前を**きっかけ**にいれかえて、応用をしてみましょう。
テレビのインタビューの質問で「きっかけは何ですか？」はよく質問されていませんか？
その後の質問は、次のかわりに今をきくことがよくありそうです。
普段の会話に応用できます。きっかけをまず質問して、次に今を質問するのです。
質問をするのに、選択肢として、きっかけ→今を　もっていると便利な気がしませんか？

**射は質問のネタに使えそうですね　川柳補足です**

- やったなら次はどうなる気になるな
- やったなら結果がわかる大切だ
雑念を振り払うためのくそWebアプリをつくる（地下鉄編）


<br>
矢印キーで、路線に沿って東京都の地下鉄駅を移動していくゲーム？を作成しました。主用途は、「プレイして仕事の心配事を一時的に忘れる」ことです。

自分本位かつ目的も楽しむことではなかったので、予定調和的にくそアプリが出来上がりました。


https://gattandgottenn.netlify.app

光が丘駅から、ランダムに選出された駅にへ向かう仕様となっています。
単に路線の終点の中から選んだだけですが、それゆえ乗り換え駅が遠く、退屈かもしれません。

---
---
---
11月ごろから、朝の5分間瞑想を取り入れることにしました。

![yoga_meisou_man.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/689316/8850825a-1666-7588-64ae-4aea233e53ac.png)

でもうまくいきませんでした。ぼーっとしようにもたくさん心配事が浮かんできます。

せめてそんな雑念を振り払う時間が取れないかと思い、１つのことに意識を集中させる何かが欲しくなりました。
ソフトウェアエンジニアだし何か製作しようと思い立ち、アプリの開発に至ります。

### 目標

要件としては、

- 簡単に作れる → webアプリかなぁ
- 面白さより操作の簡単さを求める。→ 操作が難しくて考えることが増えても仕方ないので
- 集中したい → 画面を見ないで目を閉じていてもできるものがいい → 音声を聞きつつキーボード操作で成り立つものがいい

の点をぼんやり考えていました。


### コンテンツ

東京都の地下鉄路線をモチーフに選びました。日々都内への通勤で複数の地下鉄を使っていることから思いつきました。

現在の駅から目的駅に移動するというルールなら、音で駅名を知らせていけばできます。

作るものは以下のように決めました！

0. 地下鉄の駅だけを登場させる。収集つかなくなるので。
1. ゲームを始めると、現在自分がいる駅と、目的地となる駅が表示される。
2. 矢印キーを使うと、自分がいる駅の隣の駅に移動する。また、乗り換え可能な場合は別路線の駅に移動できる
3. 隣の駅へ移動するたびに、「移動音」がなり、到着すると「駅名」が合成音声で読み上げられる
4. 目的駅に移動すると、ゴールが音声で告げられる


### 使ったもの

アプリ : svelte + typescript　
サーバー : netlify
データ : [駅データ.jp 様](https://www.ekidata.jp/) の無料データ

svelteは初挑戦で、生成AIにはかなりお世話になりました。

### アピール（くそ）ポイント

完成度を高める気がなかった言い訳はともかく、

成果物として: 
- **別に面白くはない**
- UIがちんけ
- 都内の地下鉄をそこそこ把握していないと永遠にたどり着けない。私は北東の駅が弱いです。入谷ってどこ？


技術的な瑕疵
- 合成音声のピッチなどが調整できない。くそ速い場合がある
- 読み上げられる駅名がタイポのせいで間違っている場合がある。プログラムによる読み上げのために駅名をひらがなで用意していますが、そこで入力ミスしています。
- overlayがうまく実現できていない。AIに勧められたものを確認もせずに使った。

etc.

改善の余地として前向きにとらえることにしました ♪


### プレイした感想

毎朝5minほどやってみましたが、「意識の集中」はできました。


自分の中の地下鉄地図を思い浮かべながらなので、仕事の心配事も登場してきませんでした。

なので自分的には満足です。


飽きますけどね。


### 学び

路線ごとのかぶりを含めると、300弱もの地下鉄駅があることを知りました。

ちなみにかぶりを除くと200駅ぐらいです。

しかもまだ延伸の話が出ています。発展に驚くばかり。
WebSphere Liberty Operatorでサーバーログ情報を確認

WebSphere Libertyは、Java EE / Jakarta EE / MicroProfileの実行ランタイム製品として、軽量かつ高速に起動するという特徴を持っています。これらの特徴により、コンテナ環境での迅速なデプロイやスケールアウトが可能になり、リソース消費を最小限に抑えながら複数のインスタンスを効率的に管理できます。
また、外部ツールとの親和性が高くDevOpsを実現しやすいこともあり，CI/CD環境と組み合わせることで効率的かつモダンな開発・運用環境の構築が可能になります。

コンテナオーケストレーションプラットフォームとして知られているOpenShift Container Platformの機能の中にも、「WebSphere Liberty Operator」というLibertyサーバーを効率的にデプロイ、管理、運用するための拡張機能が存在します。

本投稿では、WebSphere LibertyをOCPコンテナ環境で利用する際、アプリケーションで問題が発生した場合に重要となる、「WebSphere Liberty Operator」のサーバーログ、サーバーダンプおよびサーバートレース収集機能について、実際の操作手順を交えながらご紹介します。
これらの機能を利用することで、コンテナ内で実行されているLibertyサーバーからこれらの情報を簡単に収集でき、問題の解決に役立てることができます。


## serviceability optionの有効化
サーバートレース、ダンプを収集するには、アプリケーションを最初にデプロイするタイミングでserviceability optionを有効化する必要があります。

OpenShiftクラスターにアクセス可能なターミナルから、以下のコマンドを実行します。
~~~
oc patch wlapp <websphere-application-name> -n dev --patch '{"spec":{"serviceability":{"volumeClaimName":"<volume-name>"}}}' --type=merge
~~~
ここで、websphere-application-nameには対象となるwebsphere上のアプリケーションの名前、volume-nameには収集したファイルを保存するための永続ボリュームの名前を入力します。

有効化が成功したことを確認するには、次のコマンドを実行し、アプリケーションのステータスを取得します。
~~~
oc get wlapp <websphere-application-name> -n dev -o wide
~~~
RECONCILEDの値がTrueであれば、有効化は成功しています。

サーバーダンプ、トレースはそれぞれ必要時および問題発生時にリクエストを実行する必要があります。次のセクションからは、リクエストの実行方法について確認していきます。


## サーバーダンプのリクエスト
OpenShiftコンソール上で、[Operators] > [Installed Operators]にアクセスし、WebSphereLibertyDumpインスタンスの作成をクリックします。

次に、Licenseのチェックボックスをクリックし、podNameにLibertyサーバーが実行されているポッドの名前を入力、includeでスレッドダンプもしくはヒープダンプを選択します。
![スクリーンショット 2024-12-22 22.42.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3930287/611dbbca-b1c5-865f-348d-5d575bd09b80.png)

最下部のCreateボタンをクリックすることで、リクエストが完了し、サーバーダンプが実行されます。
ここで生成されるダンプファイルには、サーバーログ、構成、スレッドダンプもしくはヒープダンプを含むzipファイルが含まれます。


## サーバートレースのリクエスト
OpenShiftコンソール上で、[Operators] > [Installed Operators]にアクセスし、WebSphereLibertyTraceインスタンスの作成をクリックします。

次に、Licenseのチェックボックスをクリックし、podNameにLibertyサーバーが実行されているポッドの名前を入力します。
![スクリーンショット 2024-12-22 22.45.10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3930287/4a3c9d0b-019d-460c-3652-68d63567fd5b.png)
maxFileSizeとmaxFilesで、最大トレースファイルサイズとロールオーバー前の最大ファイル数を指定することもできます。
![スクリーンショット 2024-12-22 22.45.45.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3930287/96aaf046-af71-3c93-af08-f29e93d2f8e8.png)

最下部のCreateボタンをクリックすることで、リクエストが完了し、サーバートレースが実行されます。


## 生成されたファイルへのアクセス
生成されたダンプファイル、トレースファイルは「serviceability optionの有効化」で指定した永続ボリュームに保存されています。

OpenShiftクラスターにアクセス可能なターミナルから、以下のコマンドを実行します。
~~~
oc get pods
oc rsh <pod-name>
~~~
ここで、pod-nameにはLibertyサーバーが実行されているポッドの名前を入力します。

次に以下のコマンドを入力して、指定した永続ボリュームが含まれている、ポッドで実行されているコンテナ内のファイルを一覧表示します。
~~~
ls -R /serviceability/<project-name>
~~~
ここで、project-nameにはOCP上でLibertyサーバーが属するproject名を入力します。

以下に示すような出力が表示され、サーバーダンプ、トレース、ログを含むファイルが保存されていることを確認できました。
![スクリーンショット 2024-12-22 12.50.41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3930287/c38d204e-c940-3692-84e0-3d27e92f5f90.png)


## まとめ
OCPコンテナ環境でLibertyアプリケーションに問題が発生した場合に重要となる、「WebSphere Liberty Operator」のサーバーログ、サーバーダンプ、サーバートレース収集機能を確認しました。
これらの機能を活用することで、コンテナ環境の複雑性に対応し、システムの安定性と効率性を向上させることができます。

本ブログをご覧いただき、ありがとうございました。
「Reinforcement Fine-Tuning」って何者？新登場のカスタマイズ手法が面白すぎる

OpenAIが公開している「12 Days of OpenAI」シリーズ、Day 2 の動画がまたしても興味深かったので、ご紹介します。  
今回のテーマは“**Reinforcement Fine-Tuning（RFT）**”。従来の “教科書的な学習”（いわゆる**教師あり**の Fine-Tuning）とは違い、**強化学習**の手法を使ったモデルの“カスタマイズ”が実現するそうです。

この記事はChatGPT Advent Calendar 2024の7日目です（空いていたので書いてみました）今年は「12 Days of OpenAI」ということで平日毎日発表がありましたが、その内容を復習しながらまとめます

## ざっくり言うと「独自の PhD レベル思考」を作れるかも？
動画の冒頭で、OpenAIリサーチを率いる Markさんが話していたのは、「o1 というモデルをユーザー自身のデータセットでFine-Tuneできる機能をプレビュー中」ということ。  
ただし、普通の SFT（Supervised Fine-Tuning）じゃなくて “**Reinforcement Fine-Tuning**” という、OpenAIがこれまで大規模モデルの高性能化に使ってきた技術を**外部にも開放**するよ、というのがポイントです。  
現状はアルファプログラム（先行利用プログラム）で一部の大学・企業向けに提供しており、来年には一般公開を予定しているとのこと。

### 従来の Fine-Tuning との違い
- **教師あり学習 (SFT)**  
  トーンや文体などを“模倣”させるのが得意。答えのパターンを覚えさせるイメージ。  
- **強化学習 (RFT)**  
  「**どうやって**答えを導いたか」を学習させる。正解にたどり着く推論プロセスそのものを強化することで、まったく新しい領域でもきちんと推論できるようになる。

個人的には、従来の Fine-Tuning は「データセットを真似る」感が強かったのに対して、RFT は「**推論の方針自体を学習してしまう**」ところが面白いと思いました。

## 実例：希少疾患の遺伝子特定を高度にサポート
動画の後半では、バークレーの研究者 Justin さんが登場して、「希少疾患の遺伝的要因を探る」プロジェクトでの事例を紹介していました。  
希少疾患といっても全体で見ると結構な人数（3億人規模！）が該当するらしく、適切な診断がつくまでに長い時間がかかるのが問題だそうです。

- **タスク**: 症状のリスト（患者情報）から「どの遺伝子に変異があると考えられるか」を推定する。  
- **データ**: ドイツの研究機関などと共同で、過去の症例レポートをまとめた1,100件ほどの学習用データを用意。  
- **モデル**: 「o1 mini」という軽量版モデルをスタート地点に設定し、そこから RFT で強化学習させる。  

### Grader（採点者）で報酬を与える仕組み
RFTを支えるキモが、「**Grader（採点者）**」と呼ばれる機能。  
モデルが出した答え（推定した遺伝子のリスト）と、実際の正解を比較して「どのぐらい正解に近いか（0〜1のスコア）」を返す仕組みです。  
スコアが高いほど良い推論の手順を強化し、低い場合は罰則を与えるように学習を進める。まさに強化学習らしいやり方ですね。

その結果、  
- 学習前の「o1 mini」は正解遺伝子を1位に挙げられる確率が約 17.7%  
- 「o1」（上位モデル）は 25%  
- そして **RFT で鍛えた o1 mini** はなんと 31% に向上  

と、**小さなモデルでも、上位モデルを超える性能**が実現できたというお話でした。これは驚き。

## RFT の魅力と今後の展開
今回の例は「希少疾患×遺伝子」みたいな先端医療分野でしたが、OpenAI のメンバー曰く、他にも **AI セーフティ、リーガル、バイオケミカル** などの分野でも有望だそうです。  
要するに、**どうしても高度な専門家の推論が必要なドメイン**において、RFT は結構強力な武器になる可能性を秘めているんですね。

### 例：リーガル領域
動画では Thomson Reuters と組んで、o1 mini を法務アシスタント（co-counsel AI）向けに最適化している例も紹介。法律文書を読むには専門知識が必要なので、こういった領域では RFT の「解き方を学ぶ」手法がハマるのだろうと思います。

### 今はアルファプログラム参加者のみ
一般ユーザーがすぐにこの RFT 機能を使えるわけではなく、動画内でも「大学や企業など、一定の要件を満たす方は応募してね」とのこと。来年（2024年）の早い段階で正式公開を目指すようなので、興味のある方は今後のアナウンスを待つと良さそうです。  
**参考**: [Reinforcement Fine-Tuning—12 Days of OpenAI: Day 2](https://www.youtube.com/watch?v=yCIYS9fx56U)

---

全体的な感想としては、 **「理系の重厚な分野においてもAIでこんなに伸びしろがあるんだ」** というのを再確認した回でした。大規模言語モデルの潜在能力を “ちょっとしたデータセット” + “グレーダー” + “強化学習” で引き出せるなら、次世代のアシスタントは一気に専門家レベルに近づいてしまうかもしれません。来年の正式リリースが待ち遠しいですね。
Rustacean見習い🔰_環境構築

## 環境準備

Rustの環境を高速で準備します。以下は、その手順

## 手順

前提：windwos os (私はwindows11で行いました)

1. c++のbuild Toolを取得
    1. 以下のサイトから、インストーラーをダウンロード
        https://visualstudio.microsoft.com/ja/visual-cpp-build-tools/
    2. ダウンロードしたインストーラーを実行
    3. 以下は☑しておく
    　![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/333125/b6123518-4547-2406-4272-5bf0fa446dfd.png)
    3. インストール完了出来たら終わり
2. Rustを取得
    1. 以下のサイトから、インストーラーをダウンロード
        https://www.rust-lang.org/tools/install
    2. 何もきにすることなく、すべてデフォルトで実行
        一応、1) Proceed with standard installation を選びました
    3. PC再起動
    4. cargo コマンドが実行できれば大丈夫
        ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/333125/9b57902b-8076-9e33-dc09-8aac0b78ae73.png)

3. 終わり

## トラブルシューティング

### cargo runでエラー

以下のエラーがでたら、手順1-3が☑できていないので、
visualstudio installerを起動し確認してみてください
note: the msvc targets depend on the msvc linker but `link.exe` was not found
[#TiDD] 計算量から考えるチケット駆動開発の効率化

あの議論、あのファイルはどこだっけ？
あっちで探し、こっちで探し、キーワードを変えてみたり、、。
チケットで情報を適切に管理したなら、もっとうまく探せます。
チケット駆動開発を効率化する方法を計算量から考えてみました。

# 計算量とは
計算量とは必要な計算時間や必要な記憶領域の量が、入力に対してどれくらい変化するかを示す指標でO（オーダ）で示します。代表的な例を以下に示します（いい加減な説明です。ご存じの方は優しく読み飛ばしてください）。

$O(N^2)$：
バブルソートのようにデータ数（N) のループを2重に実行しないといけない場合です。データ量が増えると爆発的に処理時間が増えます。

$O(N)$：
配列のデータを探すなどデータ数（N) の単純なループで実行できる場合です。データ量に比例して処理時間がかかります。

$O(logN)$：
木構造にデータが順にある場合、木の高さだけの処理回数で検索できます。データ数がNの2分木の場合は$log_2N$になります。オーダで示す場合は底を省略して$O(logN)$で示します。データ量が増えても$O(N)$よりは緩やかに処理時間が増えます。

$O(1)$：
ハッシュや指定されたインデックスのデータを配列から取り出す場合は、データ量に関係なく、常に一定時間で取り出すことができます。これを$O(1)$で示します。

データ量によってどのように変わるかを以下に示します。$O(N^2)$が爆発的に増えているほか、$O(N)$もデータ量が増えると検索が大変なこと、$O(logN)$や$O(1)$が効率的なこと、がわかるでしょう。

|    N    |    2 |    4 |    8 |   16 |   32 |
|:-------:|-----:|-----:|-----:|-----:|-----:|
|  $N^2$  |    4 |   16 |   64 |  256 | 1024 |
|  $N$    |    2 |    4 |    8 |   16 |   32 |
| $log_2N$|    1 |    2 |    3 |    4 |    5 |
|  $1$    |    1 |    1 |    1 |    1 |    1 |

# 効率的なチケット構造
## 全文検索
全文検索でチケットを探す場合を考えましょう。
キーワードを変えながら何度か検索し、検索結果のリストからチケットを探します。検索そのものは色々な高速化の方法があるようで、大量のチケットから3秒で探せる環境もあるようです。検索そのものは$O(1)$と考えてもよいかもしれません。しかし検索結果から探す行為は$O(N)$ですし、キーワードを変えて繰り返す行為もキーワードをうまく考えないと$O(N)$になりそうです。データ量が異なる$O(N)$の処理が2重になる可能性があります。
このような全文検索を効率化するには後述の用語の統一が必要になります。

## Wiki

プロジェクトのプロセスや成果物を基準にチケットのリンクをWikiにまとめます。慣れてくると$O(1)$で探せるかもしれません。
しかしチケットの数が増えてきて、Wikiページが肥大化してしまったり、同じ項目にチケット番号を並べてしまうと$O(N)$の検索になるかもしれません。
これを改善するにはWikiを階層的に構成すると、ページを検索する部分は$O(logN)$で探せるようになるでしょう。ページの肥大化や並んだチケット番号から探すことも減るかもしれません。
しかし、そのような構造化されたWikiの作成や最新化は負担が大きいでしょう。そこで親子チケットを考えます。

## 親子チケット

チケットの親子関係を利用して木構造を作れば、$O(logN)$で検索することができます。トップレベル以外は必ず親子関係にすることをルールにすれば、容易に木構造を構築できます。プロジェクト計画や監査対象一覧をWikiにしておいて、上位のチケットをリンクしておくと便利でしょう。
木構造の検索が$O(logN)$でできる条件は、すべてのチケットが一定のルールで適切なバランスで分割できている場合です。一つの親チケットにたくさんのチケットがランダムに並んでいれば、そこで$O(N)$の検索が必要になります。また、議論の結果を知りたいのに長い議論をすべて読まないとわからないようになっていたなら、$O(N)$の検索になってしまうでしょう。後述のような運用の工夫が必要です。
（チケットシステムによっては親子関係の段数に制限があるかもしれません。その場合は関連を使うなど工夫してください）

# 効率化に向けたルール
ここまで計算量をもとにチケットの構造に関しての効率化を考えました。ここでは書くべき内容のルールで効率化を考えます。

## リポジトリとの紐づけ
チケットとリポジトリのファイル更新を紐づけることができます。複数の障害の原因になる不具合によるファイル更新時などには、複数のチケットと紐づけることで、チケットからの検索が容易になります。

## 用語や分類の統一
効率よく検索するには用語の統一や分類のルール化が必要です。全文検索でキーワードを変えたり、似て非なるチケットを探すと$O(N)$の処理になり、その回数倍の検索が必要になります。業務の用語、成果物やテストの種類、作業、といった名称を統一しておけば何度も検索をやり直したり、検索する際に迷うことも少なくなるでしょう。
仕様書の用語集や標準プロセスの定義があればそれを活用しましょう。SLCPやBOKなどの用語を標準として使うのも良いでしょう。

# 運用の工夫
ようやくチケットにたどり着いても、議論が延々と集いていて結論になかなかたどり着けなかったり、結論がよくわからず誤解することもあるでしょう。議論した後はチケットの詳細に結論を簡潔に書いておけば良いでしょう。結論がすぐにわかりますし、誤解も減るでしょう。
最近はチャット中心のツールを併用することも多いでしょう。テキストだけでなく、リアルタイムで通話できたり、会議室があったり、それぞれにファイルが置けるなど、便利ではありますが、ファイルや議論のステータスの管理が難しくなりがちです。主要なファイルの配置や議論の後は、ファイルや議論へのリンクやまとめを、チケットあるいはWikiで管理すると良いでしょう。

# まとめ
チケット駆動開発はチケットを中心にプロジェクトを回す手法です。チケットを見れば求めている情報を効率的に検索し、日々チケットを確認して開発を進める。さらにはチケットに依存して、チケットを見なければ日々の作業が進まないような文化を熟成できれば、効率的で混乱の少ないプロジェクトを実現できるでしょう。
ここで述べた内容は一例にすぎません。例えばデフォルトの担当を決めておけば、担当が割り当てられていない作業をなくせるなど、いろいろ工夫できるでしょう。皆さんの組織文化や開発体制に合わせて開発の効率化を進めてください。
kaggle tutorial bonus part 2

tutorial は終了していますが、tutorialで紹介されていた他の人のコードを見て、勉強していきましょう。

https://www.kaggle.com/code/dimitreoliveira/deep-learning-for-time-series-forecasting

の確認をしていきます。


tutorialでは、基本的に統計的なもの、time seriesについてはNNをあまり使わないような学習でしたが、ここではバンバンと使っていますので参考になります。

基本となる概念についてはしっかりと解説されていますので、ここでは補足とcodeの説明をします。


EDA：いろいろデータをいじったり視覚化しながらどのようにするかを考えること。

下の関数は、時系列データを教示ありのデータに変換しています。つまり、過去のデータ（入力特徴量）と未来のデータ（目標変数）のペアを作成しています。めちゃくちゃ便利ですね。
```
def series_to_supervised(data, window=1, lag=1, dropnan=True):
    # いろいろしている。
```
引数は

data: なんらかの時系列データをPandas DataFrame形式で渡す。
window: 過去のいくつの時点のデータを使って未来を予測するかを指定。例えば、window=3 なら、過去3時点分のデータを使う。
lag: 未来のいつの時点を予測するかを指定。例えば、lag=2 なら、2時点先を予測。


返り値はそれらを適切な形の表に直したDataFrameが返っています。

その後、それらをtestとtraningに分け・・と続いています。
何年か前のコードなので、最近見たニュースである、

https://qiita.com/s_katagiri/items/7f06ca85f851e0a50516

が頭をよぎりますね。これは改善点？でしょうか？

このあと、多層パーセプトロンを使う際の注意点を述べています。時系列データにはそれ用のNNがありますがここではシンプルなNNを使用しているので、問題があるわけですね。つまり、MLP はシンプルなモデルであるため、時系列予測に適用できるものの、データの順序情報を無視してしまうという欠点があります。そのため、多くの場合、RNN（特に LSTM や GRU）のような、シーケンス情報を考慮できるモデルの方が良い予測性能を発揮します。


このような点で問題があることを説明した上で、NNをMLP、CNN,LSTMと変えた場合の精度の違いを見せてくれています。

最後にCNNーLSTMを見せてくれています。これはCNNとLSTMの良いとこどりをしたようなモデルだということですね。

農林水産省に資料がありました。日本語の資料が読みたければ

https://www.maff.go.jp/j/shokusan/seizo/attach/pdf/vision_documents-27.pdf

をみるのが良いのでしょう。

まとめてみると、
CNN で局所的な特徴を捉え、LSTM でそれらを統合することで、長い時系列データでも効率的に学習できる。
CNN で時間的な局所パターンを抽出し、LSTM でより広範囲な時間的依存関係を学習するという、階層的な特徴抽出が可能

という点でメリットがあるそうです。デメリットは急激に学習時間が増えることですね。

最後のところで、読者が自身でハイパーパラメータ（特にウィンドウサイズやネットワーク構造）を調整し、より良い結果を追求することを推奨しています。
実際、モデルのサイズ変えてみるとどうなるのだろう。と気になった人がおられたらopotunaとかと連携して探索してみる練習になりそうですね。
原始、iPhoneは世界であった

# はじめに
インターネットの浅瀬でぴちゃぴちゃ遊んでいると、時おり見かける論争があります。
それは**Android vs iPhone。**
積極的に論争に参加しようとは思いませんが、私自身はiPhoneが（Apple製品が）好きで使っています。

さて、Android派の判断理由として、以下のような主張をしばしば見かけます。

- 右から 左へのスワイプで元に戻せないのが不便である
- 以下の機能の導入が遅かった（二番煎じであった）
    - アプリライブラリ
    - ホーム画面でのウィジェット
    - ホーム画面での間を空けてのアイコンの配置


つまるところ、「iPhoneよりも融通が利くという点で、AndroidはiPhoneより勝っている」という主張です。

私もこの主張は否定しません。
やり直すよりも元に戻したい場面が多いスマホの操作において、
右手のみで操作しているときに親指を無理に画面左端に伸ばさなくても元に戻すことができるところは、Androidを触ると特に便利に感じます。

しかしもし、**Appleがこれらの機能を意図的にiPhoneに実装してこなかった**のだとしたらどうでしょうか？
そしてその意図は「そのほうが現実世界に忠実だから」。
私はそんな妄想をしています。

ここからは、上記で挙げた機能がどのように現実世界に忠実なのかを説明していきます。

# 元に戻す
アプリなどで直前の操作を元に戻したり、前のページに戻りたいとき、
iPhoneでは画面左端から右にスワイプする必要があります。
一方Androidでは、画面左端から右へのスワイプだけでなく、画面右端から左へのスワイプでも元に戻すことができます。

先述の通り、片手で操作することも多いスマホ操作において、（右利きの場合）親指を無理に伸ばすことなく前に戻ることができるのは利便性が高いです。

しかし、**右から左へのスワイプに元に戻す操作を割り当てるのは、存外私たちの直感通りではありません。**

日本語の横書きや英語のように、多くの言語では左から右に文章を記述します。
そして横書きの文章を本にする場合、左から右にページが進むことが自然になります。
また、YouTubeなどの多くの動画ストリーミングサービスでは、動画内を移動するシークバーは時間経過とともに左から右に動いていきます。

このように、**多くの言語や文化圏では、過去（前）を左に、未来（後）を右に紐づけています。**
この紐づけをスマホの画面に落とし込もうとすると、左に存在している過去の操作やページを参照する動きとして、左から右へスワイプする操作がより直感的ということになります。

# 導入が遅かった機能
以下は、iPhoneでの導入が遅かった機能の導入時期です。
|機能|Androidでの導入時期|iPhoneでの導入時期|
|---|---|---|
|アプリライブラリ|Android 1（2008年）|iOS 14（2020年）|
|ホーム画面でのウィジェット|Android 1.5（2009年）|iOS 14（2020年）|
|ホーム画面での間を空けてのアイコンの配置|おそらくAndroid 1（2008年）|iOS 18（2024年）|

アプリライブラリや、ホーム画面でのウィジェット、ホーム画面での間を空けてのアイコンの配置は、いずれもAndroidでは初期から導入されている機能ですが、
iPhoneでは2020年以降の導入と、10年以上も遅れての導入となっています。

Appleが長くこれらの機能を導入してこなかった理由を、アプリを本にたとえて説明してみます。
よっぽどの意図がない限り同じ本を2冊買うことはなく、1種類の本は1冊のみを本棚に並べます。
1冊の本を複製して、同じ場所に複数置いたり別の場所に同時に存在させることはできません。
そしてアプリもスマホに1つのみインストールするものであることを考えると、
ホーム画面とは異なる場所に同じアプリを格納するアプリライブラリは現実世界とは乖離することになります。

また、アプリの1機能のみを表示するウィジェットも、本をスクラップする行為に近く、
原本の原型がなくなることを考えると現実世界とは乖離することになります。

さらに、本棚に本を格納するときは端から順に間を空けずに格納していきます。
これにより、ホーム画面に間を空けてアイコンを配置できなかった理由も説明がつきます。

# でも、結局iPhoneも導入したじゃん
iPhoneが現実世界に忠実だからと説明してきましたが、上記の通り現実世界にはなさそうな機能も導入され始めています。
これについては、スマホが世界の一部になったと判断したからだと思っています。
スマホのある生活が世界に浸透してきて、シェアの高いAndroidに特有の機能もスマホは一般にそういう機能があると人々が認識してきた、というようにとらえて導入を決定したのではないでしょうか。

# まとめ
iPhoneに限らず、Appleはできる限り世界を模倣したデザインと機能をデバイスに導入してきました。
デバイスにある機能を導入するか削るかにすら、AppleがGUIとOOUIを重要視し続けてきた哲学を垣間見ることができ、私の好きなデバイスとなったのでした。

妄想も入っているのであしからず。
自動化導入のコツは「百聞は一見にしかず」、見せる、使う、引き継ぐを目指そう！

# はじめに
自動化は誰もが望む反面、実際に導入をするのが難しい側面もあります。導入のハードルになる例として、「本当に動くのか」、「誰が管理するのか」などいろいろな懸念点があります。そうした懸念点を一つ一つ解決しようとしているといつまで経っても自動化は導入されません。

一方、私自身これまで様々な箇所で自動化を導入してきました。その時の経験から、どのようにして自動化を実現したかまとめたいと思います。ポイントは「百聞は一見にしかず」です。

# まずは「見せる」
自動化は、実現すれば夢のような世界が待っていますが、本当に動くのか半信半疑なために導入を躊躇することが多いと思います。そこでオススメなのがまずは「見せる」ということ。

最終的な自動化を完成させる必要はありません。すごく小さなプロトタイプでも良いので、まずは根本になる自動化ができることを示します。例えばログを自動収集する、結果を自動判断する、障害をチャットでつぶやくなど。

本当に動くものを目にすると自動化が身近になり、より話が通りやすくなります。スティーブ・ジョブズの名言に次のようなものがあります。

> A lot of times, people don't know what they want until you show it to them.
> （多くの場合、人は何が欲しいのかそれを見せてもらうまでわからないものだ）

自動化を実際に見せて「これが欲しかった！」と思ってもらう、これが自動化を成功に導く第一歩です。

# 次に「使う」
プロトタイプが動いたら、周りに宣伝しましょう。目に見える形で自動化ができると、「それができるなら、これも自動化したい」という形で周りの人を巻き込んで自動化の熱をあげることができます。そうした周りの要望を取り込むことで一丸となって自動化を推進する流れができます。またここで重要なことは疎結合および拡張性があることです。

自動化のゴールを一度に達成するのは難しく、少しずつ開発を重ねる必要があります。その時に、自分の作ったプロトタイプも採用して欲しいものです。そのためには疎結合できるようモジュール化しておくことです。モジュールもわかりやすく、例えば Python であれば pylint を通して標準的なコーディングスタイルにしておくことは、この次に述べる引き継ぐ際にも重要です。

また API など拡張可能な構成にしておくと、様々な連携が容易になります。自動化がそれ単体で完結することは珍しく、既存のシステムと何かしらの連携をする必要がでてきます。その時には API 化をしておき外部から連携しやすくしておくと使ってもらえる機会が増します。またそのようにして既存のシステムと連携すると、自動化を定着させ長く使ってもらえることにも繋がります。

このようにして自動化を実際に使ってもらうこと、また使ってもらうことを前提に拡張可能な自動化にしておくことは、自動化導入のための重要なステップになります。


# そして「引き継ぐ」
使う人が増えるとそれをカスタマイズしたいという人がでてきます。ここまできたら、ほぼ自動化をチーム内なり社内で採用してもらえるのは確実です。

しかしその時に、自分の書いたプロトタイプが解読不能では意味がありません。よってプロトタイプを書くにしても他の人が読めるように意識して書くことが重要です。そのためには、読みやすい自動化やコードにしておくことが必要です。

読み易いコードと一言で言っても様々な方法があります。lint などを通しコーディングスタイルを標準的にしておくことも重要です。また読み易いコーディングを書くための本も参考になります。例えば The art of readable code では、どのような内容をコメントにするべきか、また不要なコメントは何かなど、第三者がコードを参照する際に読みやすくする手法がとても良くまとまっています。また条件判断の際、例えば Python で示すと variable == True と書くのではなく True == variable と書くべきといったちょっとしたテクニックも載っています。等価演算子の == はしばしば代入の = のようにタイポしてしまうことがあります。この時 variable = True だと代入が成功してエラーになりませんのでデバッグが難しくなります。一方 True = variable と書いた場合は、True には代入できずエラーになり実行時にタイポを発見できます。

こうした細かな気配りができているコードは多くの人に受け入れやすくなり、自動化が浸透するために大きな役割を果たします。そして自動化を他のメンバーやチームに引き継ぐことができれば、導入は成功したと言えます。


# まとめ
シリコンバレーには Fail Fast という考え方があります。失敗はできるだけ早く修正しそこから学ぶという考え方です。自動化導入も同じで、いつかやってみようでは遅いです。

まずは自分が実装して見せる。それが上手くいかなかったらそこから学び次につなげる。上手く行ったら使ってもらい、周りを巻き込んで大プロジェクにする。そして引き継いで導入を成功させる。変化の早い今の世の中、こうしたスピード感を持った対応が必要だと思います。
「ChatGPT o1 と o1 Pro モード」登場！OpenAIが仕掛ける12日間の新機能祭りがアツい

OpenAIがこのホリデーシーズンに仕掛けてきた「12 Days of OpenAI」、初日の動画からいきなり盛りだくさんでビックリしました。何が始まるのかと思ったら、“o1” という新モデルと、その上位に “o1 Pro モード” が追加されるなんて、ほんと容赦ないですね。

この記事は[ChatGPT Advent Calendar 2024](https://qiita.com/advent-calendar/2024/chatgpt)の6日目です（空いていたので書いてみました）今年は「12 Days of OpenAI」ということで毎日発表がありましたが、その内容を復習しながらまとめます

## o1 はどこがすごいの？
まずは普通の（？）o1のお話から。もともと GPT-4.0より高性能な「o1 preview」というのを試験的に出していたのですが、今回ついに正式版 “o1” がリリースされました。何が変わったかというと、以下のように性能面でがっつり底上げされているそうです。

- **頭脳面がさらにアップ**: 数学コンペや高度なQ&A能力が向上して、コードを書くにも計算するにも頼りになる。  
- **速度面も大幅に改善**: o1 preview は「考えすぎか！」ってくらい反応が遅いときもあったけど、今回のo1はサクサク返ってくる。  
- **マルチモーダル対応**: テキストだけじゃなくて画像も理解できるようになった。手書きの数式とか、写真でアップした資料でも、「これってどういうこと？」みたいに聞くときに便利。

これらのアップデート、ユーザーのフィードバックをたっぷり取り入れたらしく、動画中でも「お前らがこうしてほしいって言うから全部やったよ！」みたいに開発陣が嬉しそうに話してました。まぁ、待望の機能が詰まってるわけですね。

ちなみに個人的には、o1 preview のときの「単に“Hi”って言っただけで10秒ぐらい考え込む」という挙動がなんだか愛嬌あって好きでした。AIが人間味を出してるというか、たかが挨拶なのに無駄に悩む感じがなんとも…（笑）。でもスピードが上がるのはやっぱり正義です。

## o1 Pro モードってさらに何が違うの？
そしてもう一つの目玉が、月額200ドルの “ChatGPT Pro” プランに含まれる **o1 Pro モード**。  
「さらなる高みに行きたい…！」というパワーユーザーのために用意された特別なモードらしく、難易度高めの数式やプログラミング、さらに複雑な推論が必要なタスクで真価を発揮するとのこと。動画内で見せていたデモでは、化学や生物系のかなりニッチな問題を解かせていて、回答を出すまでに1分とか2分もじっくり考えたりしてたんですね。それこそ研究者やエンジニア向けの超ヘビーユースに耐えるモデルという印象でした。

動画での説明を聞いていると、もう「普段使いはo1で十分だよ、でもどうしても解けない問題があればo1 Proモードに投げよう」みたいな住み分けになりそう。ゲームとかでも必殺技ゲージを溜めてドーンとぶっぱなす感じに近いかも…勝手にそんなイメージを抱きました。

## 画像で数式を解いてくれるデモがすごい
動画内で個人的に興味深かったのが、宇宙空間にデータセンターを置いた場合の放熱面積をどう計算するか、という超ニッチな問題を**手書きメモの写真**を読み込ませて解かせるデモです。宇宙だと空気や水の対流冷却が使えないので、放射熱冷却を前提にするらしいんですが、「何度で運用するか」みたいなパラメータが曖昧でもo1は勝手に補完して計算してくれる。ざっくりとした結果はサンフランシスコ市の2%ぐらいの面積が必要、というオチでした。宇宙に1ギガワット級のサーバー群置こうなんて、どんだけロマン溢れてるんだ…とツッコミたくなりますが、モデル自体はきちんと計算しているのがすごいですね。

## 開発者向けの今後の展開も期待大
今回の「Day 1」動画では、さらに「o1 APIも準備中だよ〜」とチラッと触れられていました。  
「**画像もAPI経由で扱えるようになる**」とか「**機能呼び出しやら構造化出力やら**」ができるらしく、開発者としてはたまらないアップデート。ChatGPT上で便利になった機能が、APIを通じて自分のサービスに組み込めるようになると、かなり幅が広がりますよね。ツール類が整ってきたら、もはや簡単なアプリ構築ならコード書かなくてもチャットでやり切れちゃう気もします。

---

いやはや、初日から動画15分弱の中に情報満載で、さすがOpenAIというか勢いが止まらない感じ。この先また新機能が出たら、自分の環境でも試してみようと思います。引き続き追いかけていきたいテックニュースの一つですね。気になる方は、ぜひ動画をチェックしてみてください。

**参考動画**: [OpenAI o1 and o1 pro mode in ChatGPT — 12 Days of OpenAI: Day 1 - YouTube](https://www.youtube.com/watch?v=iBfQTnA2n2s)
Apache + PHP で構成したWebサーバー上に Node.js(express)を追加する手順

## はじめに
通常はPHPでWebアプリを実行しているけど、Node.jsも併用したい場合があります(WebSocketを利用してリアルタイムに通信したい場合など)

そのような場合、Apacheをリバースプロキシとして動作させて一部のURL(パス)をNode.jsに転送することで併用することができるようになります


## 概要
http://localhost/node にアクセスがあった場合は、Node.js側で実行

それ以外ではphpで実行したい場合は、(Apacheの)リバースプロキシを利用することで実現します

具体的には、特定のパス(上記では/node)にアクセスがあった場合、Node.jsへ転送する設定を行います。
（転送時は、Node.jsのプログラムを先に起動しておいて接続待ち状態にしておきます）

ここではUbuntu環境を前提に手順を記載します


1. Apache環境の設定
    1. リバースプロキシモジュールの読み込みの設定を行う
    1. リバースプロキシの設定を追加する
2. Node.js環境の設定
    1. Webアプリを作成するための準備(express)を行う
    1. テスト用のNode.jsアプリを作成して、起動する


## 1. Apache環境の設定

### 1.1 リバースプロキシモジュールの読み込みの設定を行う

標準ではリバースプロキシモジュールが読み込まれていません

`/etc/apache2/conf-enabled` に`proxy.load`、`proxy_http.load`が存在しないことを確認後、下記コマンドでモジュールを有効化します

```
$ sudo a2enmod proxy
$ sudo a2enmod proxy_http
```

### 1.2 リバースプロキシの設定を追加する

&lt;VirtualHost&gt;ディレクティブに`/node`へのアクセスをNode.jsに転送するための設定を追加します

VirtualHostのデフォルト設定`/etc/apache2/sites-available/000-default.conf`ファイルに、下記内容を追加します

```000-default.conf
<VirtualHost *:80>
  # ～～省略～～

    # Node.jsへのリバースプロキシ設定
    ProxyPass /node http://localhost:3333/node
    ProxyPassReverse /node http://localhost:3333/node

  # ～～省略～～
</VirtualHost>

```

* `/node`にアクセスがあった場合、Node.jsの3333番ポートへ転送を行います

設定完了後、Apacheの再起動を行います

```
$ sudo systemctl restart apache2
```


## 2. Node.js環境の設定

Node.jsはインストールされている前提です

### 2.1 Webアプリを作成するための準備(express)を行う

適当なディレクトリを作成し、[express](https://expressjs.com/ja/)をインストールします

```
$ node i express
```

### 2.2 テスト用のNode.jsアプリを作成して、起動する

`/node`にアクセスがあった場合に、`Node.js`と返すテストアプリを作成します

3333番ポートで待ち受けします

```javascript:node.js
const express = require('express');
const app = express();
const port = 3333;

app.use('/node', (req, res) => {
  console.log(`${new Date()} ${req.baseUrl}`);
  res.send('Node.js');
});

app.listen(port, () => {
  console.log(`listening on port ${port}`);
});

```

テストアプリを起動しておきます
```
$ node node.js
listening on port 3333
```


## 3. 動作確認

`/node`にアクセスしたときはNode.jsで処理され、他へのアクセスはPHPで処理されていることを確認します


* `http://localhost`にアクセスしてApacheが動作していることを確認

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276579/84c91431-d9fb-ae04-b19a-5b46ebe9692a.png)

* `http://localhost/node`にアクセスしてNode.jsのアプリが処理を行っていることを確認


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276579/99808793-6a3f-249e-2b88-e3b23bb85ae0.png)

Node.jsのコンソールには、`/node`にアクセスしたログが残っています
```
$ node node.js
listening on port 3333
Sun Dec 22 2024 22:46:16 GMT+0900 (日本標準時) /node
```
【転職活動】経験年数2年なのにドラフトサービスで1位指名を3回もらえた話

# かんたん自己紹介

データ分析からエンジニアにシフトした者です。当時の経験年数は以下の通り。

- データ分析：３年
- エンジニア：2年

# 1位指名をもらったとき　

ひよっこエンジニアの私は思わずスカウトメールをお気に入りにし、スクショしました。私より経験豊富で素晴らしい経歴を持ったエンジニアの方は山ほどいます。それなのになぜ...

スカウトメールをよく読んでみると、データ分析の経験を持っていることが評価されていました。
そして、私の経験した自然言語処理の知識がプロジェクトの拡大に必要不可欠とのこと。

ちょうど生成AIも流行りだした頃でしたし、データ活用やパイプラインなどの構築も考えている企業が多かった印象です。

# いざ行かん！選考の地へ

カジュアル面談後、意気揚々と選考に進みますが技術課題でずたぼろでした...

難儀なことに、エンジニアの水準に満たなかったパターンとデータ分析の水準に満たなかったパターンの両方を経験しました。

良く言えば両刀、悪く言えば浅く広い経歴なので課題のレベルに苦戦しました。

~~(そもそも課題の量多かった:joy:)~~

せっかく期待いただいたのに、申し訳ない思いでいっぱいでした。


# 夢だけでも魅させてもらえた

1位指名ということもあり、破格の掲示年収でした。
指名をもらう前に自分のレベルを知って対策しておけば、未来は変わっていたのかもしれないです。
チャンスはいつ巡ってくるか分かりませんので、いつでも掴み取れるように日頃から準備しておくと後悔しないかもしれませんね。

# おわりに
浅く広い経歴をもった人間なので今後は深い経験をもしていきたいです。
浅く広いポジションの人が活躍する場面もあると思っているので、どういう人になりたいのかゆっくり探していきたいです。
Databricks 情報メモ

## はじめに

本記事はDatabricks アドベントカレンダー2024 22日目の記事です。

https://qiita.com/advent-calendar/2024/databricks

個人的にDatabricks情報のまとめを作りたいと思い立ち、書くことにしました。

## 企業サイト

https://www.databricks.com/jp

## 技術記事系プラットフォーム

### Qiita

#### データブリックス・ジャパン株式会社

https://qiita.com/organizations/databricks

#### Databricks Advent Calendar

https://qiita.com/advent-calendar/2024/databricks

https://qiita.com/advent-calendar/2023/databricks

https://qiita.com/advent-calendar/2022/databricks

#### まとめ記事

日々猛烈な勢いで執筆してくださっているデータブリックス・ジャパンYayoiさんの記事

https://qiita.com/taka_yayoi/items/c6907e2b861cb1070f4d

### Zenn

https://zenn.dev/topics/databricks

## SNS

#### Twitter(X)

##### 公式アカウント

https://x.com/databricks

https://x.com/DatabricksJP

##### togetter

https://togetter.com/search?q=databricks&t=q

## 技術同人誌

### 技術書典

https://techbookfest.org/market/search?q=databricks
GraphQLを1から勉強しなおしてみた ~ DataLoader ~

# はじめに
先日に引き続きGraphQLを一から勉強し直していきます。

前回はこちら。

https://qiita.com/mattsu_mocha/items/94c8f54da3a0345b2be2

# N+1問題
DataLoaderについて見ていく前に、N+1問題について再度確認していく。

**N+1問題**とは、データベースからデータを取得する際に、1つのメインクエリに加えて、関連するデータを取得するためにN個の追加クエリが発行される問題である。これにより、パフォーマンスが大幅に低下してしまう。

例として、ユーザーとユーザーに紐づく投稿を取得する場合を考える。
最初に全ユーザーを取得し（1つのクエリ）、その後各ユーザーの投稿を取得するためにユーザーごとクエリが発行されるため（N人のユーザーがいるとして、N個のクエリ）、全部でN+1個のクエリが発行される。

```graphql
query {
  users {
    id
    name
    posts {
      id
      title
    }
  }
}
```

# DataLoader
N+1問題を解決する方法が**DataLoader**である。

https://github.com/graphql/dataloader

DataLoaderを使うことで、以下の点からバックエンドへのリクエストを減らし、パフォーマンスを向上してくれる。

- **バッチ処理**: 複数のデータ取得リクエストを1つのバッチにまとめて処理することで、バックエンドへのリクエスト数を減らす
- **キャッシング**: 同じデータに対する複数のリクエストをキャッシュすることで、重複するデータ取得を避ける

以下はGraphQL、Nest.js、prismaを使ってDataLoaderを実装した例である。
（DataLoaderに大きく関係してくる箇所以外は省略している）

```prisma:prisma
model User {
  id    Int     @id @default(autoincrement())
  name  String
  posts Post[]
}

model Post {
  id     Int    @id @default(autoincrement())
  title  String
  userId Int
  user   User   @relation(fields: [userId], references: [id])
}
```

```graphql:graphql
type User {
  id: ID!
  name: String!
  posts: [Post!]!
}

type Post {
  id: ID!
  title: String!
}

type Query {
  users: [User!]!
}
```

```typescript:Resolver
import { Resolver, Query, ResolveField, Parent } from '@nestjs/graphql';
import { UsersService } from './users.service';
import * as DataLoader from 'dataloader';

@Resolver('User')
export class UsersResolver {
  private postLoader: DataLoader<number, any[]>;

  constructor(private readonly service: UsersService) {
    // DataLoaderから内部のキューに溜まった全てのキーを渡されて処理をする
    this.postLoader = new DataLoader(async (userIds: number[]) => {
      const posts = await this.service.findPostsByUserIds(userIds);
      return posts;
    });
  }

  @Query('users')
  async getUsers() {
    return this.service.findAllUsers();
  }

  @ResolveField('posts')
  async getPosts(@Parent() user) {
    const { id } = user;
    return this.postLoader.load(id); // キー(id)を内部にキューイング
  }
}
```

```javascript:Service
import { Injectable } from '@nestjs/common';
import { PrismaService } from '../prisma.service';

@Injectable()
export class UsersService {
  constructor(private prisma: PrismaService) {}

  async findAllUsers() {
    return this.prisma.user.findMany();
  }

  async findPostsByUserIds(userIds: number[]) {
    const posts = await this.prisma.post.findMany({
      where: { userId: { in: userIds } },
    });
    return userIds.map(userId => posts.filter(post => post.userId === userId));
  }
}
```
SQLの種類

## はじめに

こんにちは！今回は、SQLの主な種類である「データ定義言語（DDL）」「データ制御言語（DCL）」「データ操作言語（DML）」について簡潔にまとめます。SQLはデータベースを扱う上でさまざまな側面をカバーしており、用途ごとに異なる文法が用意されています。どの言語が何を担当するのかを把握することで、より適切なSQLコードを書けるようになります。

## 本文

### SQLの主な3種類

#### 1. **データ定義言語（DDL: Data Definition Language）**
   データベースの構造を定義・変更・削除するためのSQLです。例えば、以下のような操作が含まれます。  
   - **CREATE**：テーブルやビュー、インデックスなどの新規作成  
   - **ALTER**：既存のテーブル構造（列の追加、型変更など）やビューなどの変更  
   - **DROP**：テーブル、ビュー、インデックス、スキーマなどの削除  

**サンプルDDL**

```sql
-- テーブルの新規作成
CREATE TABLE 顧客 (
   顧客ID INT PRIMARY KEY,
   氏名 VARCHAR(50),
   登録日 DATE
);

-- テーブル構造の変更（列追加）
ALTER TABLE 顧客
   ADD メールアドレス VARCHAR(100);

-- テーブル削除
DROP TABLE 顧客;
```

#### 2. **データ制御言語（DCL: Data Control Language）**
   トランザクション制御やアクセス権限の付与・剥奪など、データベースの制御を行うSQLです。代表的な命令は以下のとおりです。  
   - **COMMIT**：トランザクションの終了（変更を確定）  
   - **ROLLBACK**：トランザクションの取り消し（変更を破棄）  
   - **GRANT**：ユーザーやロールに対して操作権限を付与  
   - **REVOKE**：付与済みの操作権限を取り消し  

**サンプルDCL**

```sql
-- トランザクション開始 (DBMSによっては明示的に必要な場合も)
START TRANSACTION;

-- いろいろなINSERTやUPDATE操作
COMMIT; -- ここで変更を確定

-- ユーザーU1に顧客テーブルへのSELECT権限を付与
GRANT SELECT ON 顧客 TO U1;

-- U1からSELECT権限を取り消し
REVOKE SELECT ON 顧客 FROM U1;
```

#### 3. **データ操作言語（DML: Data Manipulation Language）**  
   実際にテーブル内のデータを操作するためのSQLです。参照・追加・更新・削除などが含まれます。  
   - **SELECT**：データの参照  
   - **INSERT**：新規データの追加  
   - **UPDATE**：既存データの更新  
   - **DELETE**：既存データの削除  

**サンプルDML**

```sql
-- データの参照
SELECT 顧客ID, 氏名 FROM 顧客 WHERE 登録日 >= '2024-01-01';

-- データの追加
INSERT INTO 顧客 (顧客ID, 氏名, 登録日)
VALUES (1001, '山田太郎', '2024-01-10');

-- データの更新
UPDATE 顧客
SET メールアドレス = 'taro@example.com'
WHERE 顧客ID = 1001;

-- データの削除
DELETE FROM 顧客
WHERE 顧客ID = 1001;
```

### その他の利用形態

SQLコマンドは、対話型で入力するほか、アプリケーションプログラムやスクリプト言語から呼び出すことが多いです。さらに、**ストアドプロシージャ**や**カーソル**などを使って複数の操作をまとめ、一連の処理としてデータベース側に登録することで、パフォーマンス向上やネットワーク負荷軽減、セキュリティ強化などを実現できます。

例えば、アプリケーションがデータベースに接続し、ストアドプロシージャを呼び出して、複数のINSERTやUPDATEを一括で実行するなどがあります。

## まとめ

SQLは、データベースのあらゆる操作を賄うため、主に3つのカテゴリ（DDL/DCL/DML）に分けられます。

- **DDL**：データベース構造を作る・変える・壊す  
- **DCL**：トランザクション管理やアクセス権限を制御  
- **DML**：テーブル内のデータを参照・追加・更新・削除する

それぞれの特徴を理解し、使い分けることで、安全かつ効率的にデータベースを操作できるようになります。