シェルスクリプトマガジン

test

機械学習で石川啄木を蘇らせる 最終回(vol.46掲載)

投稿日:2017.04.25 | カテゴリー: 記事

written by 高橋光輝

様々なアルゴリズム・機械学習をスマートに組み合わせて未完の短歌の補完を目指した人気連載「機械学習で石川啄木を蘇らせる」。シェルマガでは同人誌から手法を発展させ、新たに記事を書き起こしてもらいました。

連載全体を俯瞰するまとめ回となった最終回を公開します。ぜひお楽しみください!

本連載のもとになった同人誌の内容は、以下のURLから閲覧が可能です。(編集部)
https://sunpro.io/c89/pub/hakatashi/introduction

遂に、機械学習で石川啄木が帰り来れり

こんにちは。高橋光輝(HN:博多市)です。今回は連載「機械学習で石川啄木を蘇らせる」の最終回として、今までに生成した、「啄木の短歌」と「ダミーの短歌」の素性ベクトルをもとに、「啄木らしさ」を学習します。その後前々回作成した「最後の一首」候補の短歌を分類器にかけ、最も「啄木らしさ」の高い一首を、復元された「最後の一首」とします。
さて、前回までの作業で「啄木の短歌」と「ダミーの短歌」の素性ベクトルを抽出し、それぞれの短歌が持つ特徴を100次元のベクトルデータに変換することができました。このように入力データを正規化し形式を揃えることによって、機械学習にとって扱いやすいデータになります。今回は「啄木の短歌」と「ダミーの短歌」を正確に分類できる分類器を作成することによって、擬似的に「啄木らしさ」の学習を行っていきます。
以前お話したとおり、分類問題は機械学習の最も基本的なタスクです。機械学習の草創期から現在に至るまで非常に多くのモデルが提唱されてきました。この連載のもととなった記事では多項ナイーブベイズ分類器を用いて分類を行いましたが、今回の連載では線形サポートベクトルマシンを用いた分類器を使用することにしました。一般に機械学習においてどのようなタスクにどのような手法が向いているのかというのを理論的に示すのは難しく、パラメーターの調整次第でいくらでも性能が変化しうるというのが機械学習の難しい部分です。今回の場合も理論的にどうこうというよりは試行錯誤を重ねたうえでの選択となっていますので、このあたりの説明の足りない点はどうかご容赦ください。

SVMをこのごろ気になる

さて、サポートベクトルマシン、略してSVMというのは少しでも機械学習を齧ったことがある方なら一度は聞いたことのある名前でしょうが、あらためて軽く解説を行いたいと思います。
SVMはおそらく、数ある機械学習のモデルの中でも特に直感的に理解しやすいモデルです。図1のように、ベクトル空間上に分類したい2種類のデータが点在する状況を考えます。これらのデータを元に未知のデータに対して分類を行うには、ベクトル空間のどの部分がどの種類のデータの領域なのかを定める境界面、つまり識別面が必要になります。

図1:SVMによる識別面の設定
SVMはこの識別面を、それぞれのクラス中で最も識別面に近いデータまでの距離、つまりマージンが最大化されるように線を引きます。この識別面の具体的な引き方を計算するには線形代数の知識が必要であるためここでは省略しますが、通常のデータでは入力されたデータからこのような識別面の解を一意に求めることができます。これが線形サポートベクトルマシンにおける「学習」です。
こんな単純なモデルで本当に「啄木らしさ」が学習できるのかと疑問に思うかもしれません。実際、線形SVMによる分類は名前の通り線形であり、非線形な処理を含まないため単体では表現力に乏しいとされています。しかし、今回分類するデータは、word2vecとsentence2vecを用いてベクトルに落とし込む段階ですでに言語の意味論的な部分をベクトル空間上に抽象化していると考えられるでしょう。word2vecによる事前学習を行ったデータがSVMやK-meansなどの比較的単純な手法でも非常に高いスコアを上げることはword2vecを提唱した論文でも示されており、これが今回のケースにも当てはまります。つまり、単語からベクトル空間へのよく学習された写像関係においては、たかだか100程度の次元で言語が持つ複雑な意味論的モデルを十分に表現できるということであり、この点からもword2vecの優秀さを伺うことができます。

SVMにさはりてみるかな

さて、話は脱線しましたが、ここからは実際にSVMを用いて「啄木の短歌」と「ダミーの短歌」を分類する分類器の学習を行いましょう。今回はscikit-learnというライブラリを使用します。scikit-learnは、機械学習の様々なモデルや、機械学習をする上で便利なツールが1つのパッケージに実装したライブラリであり、多種多様な機械学習を手軽に試せるため、機械学習の定番的なライブラリとなっています。一方、速度などの点では他のライブラリにやや劣っていますが、今回は学習するデータ数が比較的少ないため問題にはならないでしょう。
scikit-learnをインストールするために、次のコマンドを打ち込んでください。

 

では、コードを書いていきます。いつも通り、Makefileの最初にリスト1のような行を加えてください。

そして、predict_takuboku_tanka.pyというファイルを作成し、次のように記述します。

ここで、分割交差検定と呼ばれる方法を用いてSVMの精度を測定しています。分類器の精度とはすなわち分類の正確さであり、既知のデータに対してどれだけ正確に分類を行えるかを計測することによって測定できますが、このとき学習に用いたデータを測定に使用しないよう注意が必要です。学習に用いたデータは学習機にとっても既知のデータであり、正確に分類を行えるのはある意味当然であるので、精度測定が不正確になるおそれがあります。そのため、通常はデータセットを学習用のデータとテスト用のデータに分割して使用するのですが、このときの分割の仕方によって精度測定に影響が出る可能性があるため、学習用のデータとテスト用のデータを互いに入れ替えながら何度も測定を行うことがあります。これが分割交差検定です。


図2:5分割交差検定の例

今回の測定では5分割の交差検定を行っています。つまり、入力データの5分の1をテストデータに使用する測定を5回行っているということです。この測定結果は環境や乱数によって多少変動するでしょうが、おおむね97~98%程度の数値が出ると思われます。これはこの連載の元となった記事での93.3%という精度と比較しても非常に高いスコアであり、「啄木の短歌」と「ダミーデータ」との違いがよく学習ができていることが期待されます。
プログラムではその後、あらためてすべての入力データを用いてSVMの学習を行い、本命の「最後の一首」の候補を分類するための分類器を学習します。そして、それが終わったら実際にこれまでの連載で作成してきた「最後の一首」候補の短歌のベクトルデータを分類器に入力し、「啄木の短歌らしさ」の数値を推定します。これによって最もスコアが高かったものが、復元された「啄木の最後の一首」ということになります。

大跨に椽側を歩けば……

長い道のりでしたが、ようやく復元結果の発表です。それではもったいぶらずに発表しましょう。機械学習の力を借りて現代に蘇った石川啄木の最後の一首、その内容はこちらに決定しました。

大跨に椽側を歩けば、
うしなひしをさなき心
寄する日ながし。

……いかがでしょうか? 実のところ生成時に関係するさまざまな環境や乱数によって生成される短歌が異なる可能性があるので、これが唯一の解答というわけではありません。読者の皆さんが試した結果はこれとは異なる可能性があります。それぞれにそれぞれの復元結果があるということです。
「啄木らしさ」が高いと判定された短歌がどのようなものか確認するために、スコアの高かった上位30件を順に見てみましょう。

 

全体としての印象は、「かなしき」「うしなひし」「むなしき」「痛く」「冷たし」といった陰的な形容が目立ちます。この点は非常に興味深いです。以前紹介した復元結果「大跨に椽側を歩けば、板軋む。/かへりけるかな――/道広くなりき。」では「椽側を歩く」という表現から「板軋む」「道広く」といった意味的な共起表現を拾っており、この点で以前の結果は優れていましたが、一方で詩的表現の手段としての言語をあまりにも字句的に捉えすぎているという指摘も受けました。今回の結果は前回よく見られたような「板」や「道」のような前半と関連する表現は見受けられませんが、代わりにこのような精神的な表現の傾向が陽に現れたことは、ある種前回の壁を乗り越えられたといえるのではないでしょうか。
また、「眼閉ぢ眼をとづ」や「軽くかろく眺むる」といった同じ単語の繰り返しのパターンが現れているのも興味深いです。三十一文字の中で同じ表現や単語を繰り返すのは特に前期啄木に見られる技法であり、「なみだなみだ/不思議なるかな/それをもて洗へば心戯けたくなれり」「はたらけど/はたらけど猶わが生活楽にならざり/ぢっと手を見る」といった歌にみることができます。この結果に出てきている用例はかなり露骨でありあまり高く評価はできませんが、もしかしたらこのような表現パターンを入力データから学習しているのかもしれません。
というわけで、今回の復元結果はこのようになりましたが、この結果は学習のパラメータや手法次第で大きく変わる可能性があります。読者の皆さんはぜひ、各種パラメーターを変更して、より望ましい結果が得られるように調整してみてください。たとえば、

・形態素解析に用いる辞書データの変更
・RNNLMやマルコフ連鎖で生成する短歌の数の変更
・マルコフ連鎖で用いるn-gram辞書のnの値の変更
・RNNLMに渡す各種パラメーター
・分類器のパラメーターの変更、もしくは探索※2

などは試してみる価値があると思います。

ひよつとした事が、思ひ出の種にまたなる

さて、こうして無事石川啄木の最後の一首を復元することができたので、おさらいをする意味も込めて本連載の流れをもう一度最初から振り返ってみましょう。


第1回(編:本誌 vol.38掲載)では、イントロダクションとして、本連載の中心人物である石川啄木の紹介、そして石川啄木の未完の「最後の一首」の解説を行いました。
第2回(vol.39)では「最後の一首」復元の第一歩として、青空文庫から原本となる啄木のテキストを取得し、短歌の部分を切り出してパースする処理を行いました。
第3回(vol.40)では、第2回でパースしたデータを形態素解析にかけ、短歌がどのような語句で構成されているのかを解析しました。
第4回(vol.41)では、第3回で形態素解析したデータを元にマルコフ連鎖を行い、文章としての繋がりを重視するプローチから「最後の一首」候補を作成しました。
第5回(vol.42)は第4回と並行する形で、今度はRNNLMを用いて「最後の一首」候補を作成しました。こちらはどちらかというと文脈を重視したアプローチになります。
第6回(vol.43)では、第4回と第5回で作成した「最後の一首」候補から、短歌の形式をとっているものをフィルタリングする処理を行いました。ここで単語列を文節に分けるテクニックを解説しました。
第7回(vol.44)では、短歌形式を取っている「最後の一首」候補を、word2vecとsentence2vecを用いて素性ベクトルに変換し、機械学習で扱いやすい形に変換しました。
第8回(vol.45)では機械学習による分類を行うための前準備として、「石川啄木らしくないデータ」、つまりダミーデータを生成する処理を行いました。また実装は行いませんでしたが、類似技術であるGANについても同時に解説を行いました。
そして第9回となる今回では、第8回で生成したダミーデータと啄木の短歌を正確に分類するSVMを学習し、それを用いて第7回で生成した啄木の「最後の一首」候補の「啄木らしさ」を推定し、もっとも「啄木らしさ」の高い一首を復元された「最後の一首」としました。

こうしてみると、「石川啄木の最後の一首を復元する」という一つのタスクに対して、様々な技術が複雑に関係していることがわかります。啄木の歌集の校訂者に端を発し、形態素解析器、マルコフ連鎖、RNNLM、word2vec、SVMと、どれも偉大な先人が築き上げてきた技術の集大成です。現代に生きる我々の使命は、折りに触れてなるべく広範な知識を身に着け、こうして巨人の肩の上に立ち、その上でどれだけ新しい価値を生み出せるかということに懸かっていると思って止みません。みなさんもこの連載記事を通じて、石川啄木や自然言語処理、さらに機械学習に興味を持って頂けると幸いです。
それでは、以上で連載「機械学習で石川啄木を蘇らせる」最終回とさせていただきます。9回の長い間お付き合いくださりありがとうございました。また機会があればどこかで会いましょう。

あなたにとっての技術が、物語のよき隣人でありますように。

 

本記事は、シェルスクリプトマガジンvol.38~vol.46に掲載された連載の最終回です。それぞれの技術の詳細については、該当のバックナンバーをご参照ください。(編集部)

ITエンジニアのサボりに強い味方現る!シェルスクリプト製ライフゲーム

投稿日:2017.04.18 | カテゴリー: 記事


written by シェルスクリプトマガジン編集部

(本記事はWeb版シェルスクリプトマガジン独自記事です)

USP研究所技術研究員 ナカムラ氏謹製の、シェルスクリプト製 ライフゲーム・シミュレータをご紹介します。
インストール・設定・操作・実行のすべてがターミナル画面上で完結するので、上司の目が厳しいエンジニアの皆さまも、いかにも「仕事中です」という顔をしながら暇つぶしに勤しめます。

ライフゲームとは

ライフゲームは、1970年にJohn Horton Conwayが発明したコンピュータ・ゲームです。
マス目(セル)のオンオフを生命(例えばシャーレ上に培養される微生物)に見立て、単純な規則により時間経過による生命の繁殖を表現します。
自分の周り八方のセルの密度が適度なら次のターンに培養される、過疎もしくは過密の場合は死滅します。

ルールは簡単ですが、初期状態からは想像もつかない形へと発展していく面白さがあります。。

例:代表的なパターン「グライダー」。 4世代ごとに縦横1マスずつ移動しながら元の形に戻ります。

→ 

 

ライフゲームのルール(引用元:「ライフゲイムの宇宙 新装版」ウィリアム・パウンドストーン著 有澤誠訳、日本評論社)

Wikipedia「ライフゲーム」などもご参照ください。

 

遊び方

インストール

コードはGitHub上に公開されています。

https://github.com/kaznak/ConwayGoL.sh

ターミナル画面上で $ git clone https://github.com/kaznak/ConwayGoL.sh.git とすることでインストールできます。

ConwayGOL.sh/ のディレクトリに移動し、初期化コマンド . rc を打ち込むことで準備が整います。

 

サンプルパターンを実行してみよう

ライフゲームの面白さは、初期のセル配置パターンからは想像もつかない発展をとげることです。

ConwayGoL.sh/example-pattern/ に、特定の動きをする代表的なパターンが収録されています。

まずはそれらのサンプルパターンを実行してみましょう。

例えばさきほど紹介した「グライダー」を見たいときは、 ConwayGoL.sh/ ディレクトリで以下のコマンドを実行します。

上司に見つかりそうになったら Ctrl-C を長押しすれば終了できます。

また、一世代ごとの移り変わりを確認したいときには、conwaygolコマンドにオプションをつけます。

conwaygolの後に続くオプションのうち、

最初の「2」は初期状態から2世代後まで(計3世代)を表示することを示します。

後ろの 10 10 は、セル全体の大きさの指定を示します。

 

自分で作ったパターンを実行してみよう

サンプルパターンを動かしてみたら、いよいよ自分で初期パターンを作り、実行してみましょう。

まずはテキストエディタを使って、ConwayGoL.sh/example-pattern/ に初期状態のファイルをつくってみましょう。

オンのセルはX(半角の大文字X)で、オフのセルは半角スペースで打ち込みます。

それではこいつを実行してみます。

題して、「ライフゲームで占うシェルマガの未来」。

(GIFファイルです)

実行当初からどんどん形が崩れていきます。あははは、これは愉快だ。

途中からは、文字の区切りの痕跡すら残っていません。

(GIFでは飛び飛びですが)約300世代後、ふたつのパターンを繰り返す定常状態になりました。

シェルマガがこれからどんどん広まり、vol.300近くまで続くというお告げでしょうか。素晴らしい。

 

おわりに

というわけで、USP研究所ナカムラ氏謹製 シェルスクリプト版ライフゲームのご紹介でした。

みなさまの、仕事してるフリをしながら適度にサボる、豊かなITエンジニア・ライフのお役に立てますと幸いです。

詳しい操作の仕方については、インストール後 readme もご参照ください。

 

シェルスクリプトマガジンは、明日すぐには役立たないけれども数年後の自分の血となり肉となる、ITエンジニアの教養満載でお届けしています。

データ分析、IoT、PM、ネットワークなど、新しい勉強を始める春にぴったり!最新号vol.47はこちらから!

 

「無意味な行動をとらせる力」を使え! 環境ITベンチャー ピリカのつくりかた

投稿日:2017.04.4 | カテゴリー: 記事

本記事は、シェルスクリプトマガジンvol.47掲載「技術者哲学 ピリカのつくりかた」のダイジェスト版です。

株式会社ピリカは、『科学技術の力であらゆる環境題を克服する』と謳い、ポイ捨ての解決をビジネスにしているITベンチャーです。
実際に彼らのゴミ拾いアプリ【ピリカ】を使ってみると……

 「ゴミが落ちてるぞ!」

「拾って写メを撮って…」

「ピリカに投稿だ」

「拾ったゴミはゴミ箱へ」

(数時間後)「お、【ありがとう】がたくさんついてる。いいことした気分!またゴミが拾いたくなってきた」

 

と、一見結びつきそうにない【IT】と【環境問題】と【ビジネス】が、たしかに融合していました。

この秘密を探るべく、編集部は開発元の株式会社ピリカを訪れました。

インタビューに応えてくれたのは代表の小嶌不二夫さんとCTOの高橋直也さん。起業に至った経緯、環境問題にIT技術ができる貢献、そして今後の展望を伺ってきました。
(聞き手・まとめ シェルスクリプトマガジン編集部)

 

ピリカができるまで

―今日はよろしくお願いします。まずは、小嶌さんが「IT技術で環境問題を解決するビジネス」を始めるに至った経緯を聞かせていただけますか。

小嶌:僕が環境問題に興味を持ったのは、小2のときに読んだ、ポプラ社の「地球の環境問題」シリーズがきっかけです。図書室の隅っこにあったこのシリーズに異常にハマって、同じ本を何度も借り直した記憶があります。その頃の僕は「大きな問題を解決する」ことに魅力を感じたのでしょう。もちろん、大人になってから勉強し直すと当時とは状況が変わっているわけですが、最初のきっかけはこのシリーズでした。

 

―環境問題の解決に取り組むうえで、起業という形をとったのは何故ですか?

小嶌:大学に入った頃は研究者を希望していました。でも、学部四年で研究室に配属になったら、二週間くらいで「これ、全然面白くないな」と思ってしまい、そこで研究者の道は諦めました。割り当てられた研究が合わなかったということもありますし、「研究者として」環境問題にアプローチするのは、自分の場合はちょっと違う、とも思い始めたからです。当時の僕の視点からは、研究とは「人生を賭けてひとつのテーマをひたすら深掘りする」ものに見えたのですが、そうすると、僕が小学生の頃読んだ本の「一冊分」は解けるかもしれないけれども、「残りの分」が解けないじゃないですか。

―たしかにそうですね。

小嶌:一方で、「お金」だったら全てのことに使えますよね。ひとつの事業で得たお金を他の分野に転用していくことができますから。そこで、学部四年で「研究面白くないぞ」と感じてからは、自分で事業を立ち上げるのか、それとも仕事を学ぶためにまずは企業に就職するのか、大学院でのモラトリアムの間に自分の道を決めることにしたんです。だから、大学院に入ってからは海外で働いてみたり、色々な国を旅してみたりしました。

―なんとなく大学院に進んでモラトリアムを過ごす、という人は多いですが、小嶌さんは環境問題にどう取り組むべきか見定めるために、モラトリアムを「積極的に取りにいった」わけですね。その結果「ゴミ問題」を選んだのは何故ですか?

小嶌:ひとつはお金の問題です。環境問題の範囲はとても広いわけですが、多くの問題は解決に莫大なお金がかかりますよね。浄化フィルターひとつ開発するのにも何千万円もかかってしまう。だから「安く始められること」が絶対条件だったんです。
一方で、安く始められたとしても「汚染を除去するフィルターの、この一部分だけを作りました」で終わっては悲しいですし、全体の問題の解決には到底達しません。そこで、「将来的には大きな広がりを持っているけど、入り口は小さい」テーマとして、ゴミ問題に取り組むことにしたわけです。

―なるほど。

小嶌:世界一周旅行をしていた当時、100くらいアイデアをメモ帳に書きためたんですが、結局「これだったらいけるかもしれない」と思えたアイデアは、その中の3つくらいを組み合わせた1つだけでした。
それは「Googleマップのような地図に、色々な環境問題の情報を載せ込む」ことです。
これまでにも、様々な自治体さんや団体さんが地域の問題解決をしようと努力されていますが、その中には、「『○○川を綺麗にしよう』という活動が盛んだが、実際にはその隣の川の方が汚い」のような状況が結構ありますよね。そういう状況に対して、位置情報付きで環境問題の見える化をすることで、環境問題を解決しようとしている人の行動を最適化したり、関わる人を増やしたりできるのではないかと思ったんです。

―最初のアイデアは「環境問題のマッピング」だったんですね。スマホにピリカをインストールすると、道端でゴミを見つけたときに自ずと拾いたくなってしまうので、よく出来た仕組みだと感心しています。この効果は狙って設計したんですか?

小嶌:まさに、世界の国を旅している間にそれと同じ体験をしたんです。iPhoneを持って旅に出たんですが、スマホの位置情報をオンにして写真を撮ると、現在地がマップにピン留めされるじゃないですか。アフリカの街にいるときに、ピンがもう世界を半周していることに気がついて、「おっ、これは面白いな」と思ったんです。なにか、色々な街を征服したみたいで。そこからは無意識に、新しい街についたら意味もなく、位置情報をオンにした状態で写真を撮るようになっていきました。部屋の隅とかでもとりあえず撮るんですよ、位置情報を刺したいから。

―「ピンを刺すこと」自体が目的になってしまったんですね。

小嶌:後から振り返ってみると、「なにこの無意味な写真」って思うわけですが、これって、要はゲーム性とか面白さによって人に「無意味な行動」をとらせているってことですよね。

―たしかにそうです!

小嶌:人にこういう無価値な行動をとらせられるなら、もしかしたら情報くらい送ってくれるかもしれないし、ゴミくらい拾ってくれるかもしれない。「位置情報付きで写真を撮ること」にそういう力があるのなら、これを使って面白いことができるかもしれないと思ったんです。

 

環境問題をビジネスにする

―大学院での経験をヒントにして始まったピリカですが、株式会社ピリカが現在展開されている事業を紹介していただけますか?

小嶌:現在はスマホアプリ「ピリカ」を使ったゴミ拾い支援事業と、画像認識システム「タカノメ」を使ったポイ捨て調査事業の二本立てです。ゴミ拾い事業の収益は、様々な企業さんからの広告・協賛と、ピリカの仕組みを使ってくださる地方自治体さんからのシステム利用料です。タカノメによる調査では、案件ごとに調査面積に比例した調査費用を頂き、得られたデータを基にした研究成果に対しても研究費用を頂いています。

―どんな組織がタカノメによる調査・研究のクライアントになるのですか?

小嶌:協賛企業でもあるJTさんを例に挙げて説明しましょう。タバコのポイ捨てはJTさんにとってもデメリットですよね。ポイ捨てがあまりに酷いとクレームが来たり、場合によっては自治体に喫煙所を作らせてもらえなくなったりしますから。ですから、喫煙所をどうデザインすれば地域のポイ捨てを抑制できるのか、喫煙者・非喫煙者双方にとって暮らしやすい町や制度を作れるか、ということを研究する動機がJTさんにはあるわけです。このケースでは、自治体・JT・ピリカで協定を結び、データと費用を頂いて調査を行っています。

―タカノメによる調査費用は調査面積に比例するとのことですが、どのようにサービスの価格を決めたのですか?

高橋:タカノメに関しては、面積に原価が比例するのでそこに値段つけたということですね。

小嶌:買い手のことを考えると、自ずと売り方が決まってくるという面もあります。環境問題のビジネスとしての特殊性は、直接的なお客さんであるゴミや大気、川や海からはお金をとれないことですよね。

―そうですね。

小嶌:だからその代わりに、問題を抱えている「人の問題」として売るしかない。「ポイ捨ての問題」では売れないので、見方を変えて「地域の美化」の問題として扱って自治体の地域美化の担当者さんに買ってもらう、河川の問題として切り分けて、喫煙所の問題として切り分けて……という発想に、どうしてもなります。そこで、ときには相手に尋ねながら「買ってくれる方法」を探すわけです。例えば自治体を相手にするなら、議会を回さずに使える予算はそれぞれの市区町村によって違いますから、それらに柔軟に対応でき、なおかつ予算に合わせて調査規模を拡大できるような売り方になります。

 

環境ベンチャーのエンジニア

―現在CTOとして開発を担当されている高橋さんは、どのような経緯でピリカにエンジニアとして参加されたのですか?

小嶌:システム開発の会社に就職した大学時代の友人に「ピリカを作っていく上でどうしてもエンジニアが必要なので、周りで一番優秀な人を紹介してもらえないか」と頼んだら、その場で電話をかけて、同僚だった高橋さんを紹介してもらったんです。

―え、そんな簡単に決まったんですか?

高橋:参加といっても、最初の3年間は週に2時間くらいでした。普段の仕事とは別のことに関わっていたいという希望はその前から持っていましたし、実際にピリカに関わる2時間がいい気分転換になって、普段の仕事でも楽しくいられたんです。ピリカをやっている間にも、もう一社並行でやっていたこともあります。ピリカにフルタイムで関わるようになったのは、私も東京に出て来てからですね。

小嶌:高橋が参加した当時は二人とも関西にいましたが、それからすぐ僕は東京に出て来ました。なので、遠隔でのやりとりの期間が長かったですね。現在でも、当時の高橋のように他の仕事をしながら関わってくださる方や、北海道やアメリカなど遠隔で関わってくれる方がいまして、30名近い方の力を借りて事業を行っています。

―アイデアを出す小嶌さんと、それをシステムで実現する高橋さんは、どういう関係で仕事を進めているのでしょうか?

高橋:自分が関わる部分については、割とやりたいようにやらせてもらっています。基本的に、作りたくないものを作ったことはないはずで、「何を作るか」を決める時点で自分の意見をある程度反映させています。

小嶌:例えばタカノメは、そもそものサービスの構想自体が高橋の発案です。私が持っていたのは「ゴミの種類と数を、安く、正確に、そして様々な場所で同じ基準を適用して調査したい」という方針だけでした。それを人力でやるにはお金もかかるし、限界もある。なによりも面倒な作業ですから、やる方が幸せになれないですよね。その解決のために「スマホで写真を撮って、画像解析でゴミを見つける」というシステムの大枠を考えたのは高橋なんですよ。

 

 

シェルスクリプトマガジンvol.47に掲載の本記事ロング・バージョンでは、科学技術・ITが環境問題にできる貢献について小嶌さんが考える「ピリカの基にある哲学」を、よりつっこんで伺っています。

 

 

ユニケージ開発手法 コードレビュー vol.36(本誌vol.47掲載)

投稿日:2017.03.31 | カテゴリー: 記事

著者:USP研究所技術研究員 岡田健

 今回は、シェルスクリプトのデバッグを行いたい時、処理の途中or一部だけに限定して実行出来る uspTukubai のコマンド「run」を紹介します。

本記事掲載のシェルスクリプトマガジンvol.47は以下リンク先でご購入できます。
USP研究所 通販サイトでは、個人用uspTukubaiのご購入も可能です。

 

香川大学SLPからお届け!(vol.47掲載)

投稿日:2017.03.28 | カテゴリー: 記事

著者:石井怜央(香川大学SLP)

 前回は、OSC広島の前日に行われた学生LT大会の様子を紹介し、その中で僕が発表した、サークルで開発を行ったメール管理システムについて触れました。
 今回はその開発で使用した、Sinatraやmail gemについて紹介し、それらを組み合わせて簡単なWebアプリケーションを作成したいと思います。

記事本文掲載のシェルスクリプトマガジンvol.47は以下リンク先でご購入できます。

40歳から始める、オレとRubyプログラミング(vol.47掲載)

投稿日:2017.03.24 | カテゴリー: 記事

著者:しょっさん

 最近、自宅で二酸化炭素濃度をはかるようになりました。 予想していた以上に、家の中の空気が汚染されていることがわかって、衝撃を受けています。部屋が暖かいから眠くなるんだなー…なんて考えていましたが、暖かいんじゃなくて二酸化濃度が高いからという可能性が高いです。
 二酸化炭素濃度を下げるには、換気をすることが基本ですが、この濃度を下げてからというもの、家での活動がとてもスムーズになり眠くなることが減りました。
 なんでこんなことしてるのかって? もちろん、クリアーな頭の状態でプログラミングするため。さぁ今月も頑張っていきましょう!

記事本文掲載のシェルスクリプトマガジンvol.47は以下リンク先でご購入できます。

リスト6-a、6-bは本来ひとつのコードですが、本Webサイトの文法に抵触するため分割して掲載します。

バーティカルバーの極意 第一回 (vol.47掲載)

投稿日:2017.03.24 | カテゴリー: 記事

著者:中央大学 教授 飯尾淳

 この連載では、バーティカルバー、あるいは、縦棒で表される記号(|)や縦棒そのものを中心として、話題を展開しようと試みます。毎回、どんなバーティカルバーが現れるか、楽しみにしていてください。…といいつつ、第1回めの今回は、皆さんおなじみ、Unixにおけるパイプ(|)を扱います。ベタでどうもすみません。

記事本文掲載のシェルスクリプトマガジンvol.47は以下リンク先でご購入できます。

無料無線公衆LANスポットのCSVファイル URL
http://www.data.go.jp/data/dataset/mlit_20160325_0037

逆に、Tukubaiコマンドをシェルスクリプトで実装してみる 前編 (vol.47掲載)

投稿日:2017.03.24 | カテゴリー: 記事

著者:今泉光之 (Twitter: @bsdhack)

 

1 usp Tukubai とは?

usp Tukubai は ユニバーサル・シェル・プログラミング研究所が開発・提供している一連のコマンド群で、商用製品として様々な分野の数多くのプロダクトとして利用されているソフトウェア製品です。
usp Tukubai はコマンド群として提供されており、通常の UNIX コマンドの様に複数のコマンドを繋ぎ合わせて使うことでシステムを構築することができます。
usp Tukubai で提供されるコマンドを使いこなすと、端末だけで集計処理ができたり、ファイルだけでDBを組んだり、ウェブシステムを組んだりと、シェルあるいはシェルスクリプトでできることが飛躍的に増えます。
特に製品版として開発されている usp Tukubaiはソースコードのレベルからチューニングされているので、非常に高速に動作するので大規模なエンタープライズシステムでの使用にも十分に対応できる性能となっています。

2  ユニケージ開発手法とは?

ユニケージ開発手法はユニバーサル・シェル・プログラミング研究所によって開発された、短期間低コストで企業システムを構築するための開発手法です。
小さなコマンドを組み合わせて問題を解決することを目的とした開発手法やコマンドに関する研究開発に取り組んでいるユニバーサル・シェル・プログラミング研究所が、そうした研究開発の成果をまとめた開発手法がユニケージ開発手法です。
本稿で扱う usp Tukubai はユニケージ開発手法を実践するための手段として開発されたコマンド群です。
ユニケージ開発手法に基づいて usp Tukubai コマンドを利用することで、数十行のプログラムでアプリケーションを記述できたり、データベースを使わずにテキストファイルのみでデータ処理が可能となります。実際にユニケージ開発手法に基づくシステム開発は小売業を中心に基幹業務システム、情報分析システム、データバッチ処理、高速検索システム、勘定系システムなど様々な分野で活用されていて、特にシステムの内製化を進める企業において採用されています。

3 Personal Tukubai とは

usp Tukubaiを試用目的で利用できるようにしたバージョンで、商用利用はできません。
Windows、Linux、OS Xでそれぞれ動作するので usp Tukubai による業務システムの開発を実際に体験できます。
期間限定のライセンスで、ダウンロードした月から 6ヶ月後の月末まで使用可能となっているので、十分に usp Tukubai の機能を調べることができると思います。

4 Open usp Tukubai とは

usp Tukubai コマンドのうち、利用頻度の高いコマンドを厳選して Python により実装しなおし、MIT ライセンスの下でオープンソースソフトウェアとして提供されているのが Open usp Tukubaiです。
製品版の usp Tukubai と比較すると一部実装されていないコマンドがあったり、性能にある程度の差は出てしまいますが、それでも usp Tukubai の便利な機能を知るためには十分に有用だと思います。
本稿では、Open usp Tukubai についての解説となります。

Tukubai 各コマンドの機能の紹介と簡単な解説

1 Open usp Tukubai のインストール方法

Open usp Tukubai は Python により実装されているので Python が動作する環境であればインストール可能です。
公式の配布サイトからソースを取得して展開し make install するだけで Open usp Tukubai は利用可能となります。
OS X 11.6 (OS X El Capitan) では以下のコマンドでインストールできます。
$ curl ‘https://uec.usp-lab.com/TUKUBAI/DOWNLOAD/open-usp-tukubai-2014061402.tar.bz2’ -o open-usp-tukubai-2014061402.tar.bz2 $ tar zf open-usp-tukubai-2014061402.tar.bz2 $ cd open-usp-tukubai-2014061402 $ sudo make install

2 Open usp Tukubai コマンドの解説

ここでは Open usp Tukubai のコマンドを解説します。
ただし以下のように Open usp Tukubai だけでも 55 コマンドも提供されており、その全てを解説するのは無理なので、
特に有用で興味深いコマンドを厳選して紹介します。

また、シェルスクリプトマガジンに掲載の記事なので、シェルスクリプトで Open usp Tukubai コマンドを実装してみたいと思います。今回は、calclock、comma、getlast、ketaの4つのコマンドを紹介し、シェルスクリプトでの再現を試みます。
但し今回は紙面と時間の都合で一部の機能やオプションなど実装できていない部分も多いです。
また、動作の把握とメイン処理の実装のみに絞ったので、エラー処理などはまったく実施していません。
そのために実際の業務などには殆ど利用できない実験的なスクリプトとなっています。

calclock

1 calclock とは

オンラインコマンドマニュアルはこちら

入力データ(ファイルや標準入力)の指定されたフィールドのデータを Epoch *1からの秒数に変換してフィールドの隣に出力します。
ファイル名に – が指定された場合は一般的な UNIX の流儀にのっとり標準入力を入力として利用します。
入力データは年月日(yyyymmdd形式)、時間(HHMMSS形式)、年月日時間(yyyymmddHHMMSS)を自動で検出します。
例えば以下の様なフォーマットのシステムへの接続ログから接続時間を取得する処理などを簡単に作ることができます。

*1 Epoch とは UNIX で一般的に利用されている時刻表現で、協定世界時(UTC)での1970年1月1日午前0時0分0秒の時刻からの形式的な経過秒数です。

calclock 唯一のオプションは -r で、これを指定すると入力データは Epoch からの秒数として解釈され出力は年月日時間(yyyymmddHHMMSS)となります。

2 calclockを作ってみよう

シェル組み込みのコマンドと date(1) を駆使して、何とか似た機能は実現できました。
引数で指定されたフィールドを変数 fields に格納しておき、read(1) で入力した行データ毎に fields に格納されたフィールドから date(1) で秒数を取得し、取得できた秒を変数 v数字 (数字はフィールド番号) に格納しています。指定された全フィールドの処理が終わると、入力データと取得した秒数を出力します。入力データの指定されたフィールド形式などのチェックしていないので、入力データに不正な値があると正しく動作しません。また、今回は -r オプションに関して実装しておらず、入力データも標準入力のみとなっています。

comma

1 comma とは

オンラインコマンドマニュアルはこちら

入力データ(ファイルや標準入力)の指定されたフィールドのデータを「カンマ区切り」にします。帳票データなどの最終的な出力に適用すると、金額などの可読性が向上します。
指定したフィールドに数字以外のデータが入力された場合はエラーとなります。

+hオプションはヘッダ行をスキップするための指定で、指定された行(デフォルトは1行)をヘッダ行としてスキップします。

d オプションは引数で指定した文字列をカンマ区切りにします。

-4 オプションは 4 桁区切りにします。

2 commaを作ってみよう

メインのロジックは awk(1) を利用することで何とか実装できました。
awk(1) の substr 関数を利用して文字列の後ろから指定された桁数で文字列を切り出し、切り出した文字列の先頭に , を付けることでカンマ区切りを実現しています。
今回は -d オプションに関して実装しておらず、入力データも標準入力のみとなっています。また Open usp Tukubai の comma では桁区切りするフィールドのデータをチェックしていて、データが数字以外の場合はエラーメッセージを出力していますが、こちらのスクリプトではその様なエラー処理をしていません。
ちなみに 3 桁区切りだけでよければ printf(1) の %’ を利用することでも殆どの場合実現可能ですが、printf(1) の %’ は現時点では非標準なので全ての環境で利用できる保証はなく、また、区切りを 4桁にする機能は対応していないので、独自に実装する必要があります。

getlast

1  getlastとは

オンラインコマンドマニュアルはこちら

入力データ(ファイルや標準出力)の指定されたフィールドの値が最後に出現した行を出力します。

同一のフィールドを指定することで単一のキーフィールドの指定も可能です。
以下の例だと第1フィールドの値のみで抽出しています。

+ng オプションは同じ値を持つ最後の行以外を出力します。

2 getlastを作ってみよう

メインのロジックは awk(1) のハッシュ (連想配列) を利用することで実装しました。
指定されたフィールドの値をそのまま連結してハッシュのキーとして利用することで、最新の行内容がハッシュに格納されます。
awk(1) の仕様としてハッシュの順番はランダムになりますので、
順番を維持するためにハッシュに格納する行データに行番号を付与して、出力したデータを sort(1) を利用して行番号でソートして正しい順番に並べ替えた後で、cut(1) で追加した行番号を削除して出力しています。
メインのロジックは awk(1) の機能をそのまま利用することで実現できたので、今回実装したコマンドの中では一番短く単純なスクリプトになっています。
+ng オプションは実装していません。

keta

1 keta とは

オンラインコマンドマニュアルはこちら

入力データ(ファイルや標準出力)の指定されたフィールドの桁数を揃えて、右詰で出力します。
表示するための最大幅は自動で計算されます。

— オプションは左詰で出力されます。

フィールド毎に出力する桁数を数字で指定することができ、指定する数字に – を付けることで左詰を指定することもできます。
出力する桁数は半角文字の表示幅を 1 としているので全角文字の場合は 1 文字を 2 とする必要があります。

2  ketaを作ってみよう

基本的な機能は全て awk(1) の組み込み関数で実装しました。
入力データは行番号とフィールド番号をキーとしたハッシュ dataに格納し、同時にフィールドの文字列長の最大値を別のハッシュ max に格納しています。
出力は、 awk(1) に組み込みの printf の %*s 指示子を利用することで出力幅を指定しています。

マルチバイトの文字列には対応していないので、入力データにマルチバイト文字があると正しく出力できません。
非英語圏でマルチバイト文字が正しく扱えないことは致命的ですので、業務には利用できません。

UTF-8 では、マルチバイト文字は多くの場合 3 バイトかそれ以上のバイト数を必要としていますが、OS X 標準の awk(1) の lengthコマンドは文字列のバイト数を取得しますので、例えば length(“あ”) は 3 となります。
Linux で標準的に利用されている GNU awk の場合はマルチバイト文字に対応していますので、マルチバイト文字を含む文字列の長さは正しい文字数を取得することができ、length(“あ”) は 1 となります。
しかしマルチバイト文字は 2 バイト相当の表示幅となりますので、どちらの場合でもマルチバイト文字を含む文字列の長さと表示幅は合致しません。
そのためにマルチバイト文字を含む文字列を表示する幅を正しく制御するのは非常に困難となります。

-v オプションは実装していません。

5/25発売のシェルマガvol.48では、さらなるTukubaiコマンドに挑みます
Web版シェルマガにも公開しますので、どうぞお楽しみに!

本記事掲載のシェルスクリプトマガジンvol.47は以下リンク先でご購入できます。
USP研究所 通販サイトでは、個人用uspTukubaiのご購入も可能です。

漢のUNIX 静的ライブラリをつくってみよう (vol.47掲載)

投稿日:2017.03.24 | カテゴリー: 記事

著者:後藤大地

 前回の記事では、実装を複数の.c ファイルに分けて作成し、それらをコンパイルして.o ファイルに変更し、その.o ファイルを組み合わせてバイナリファイルを生成することを説明した。
 .o ファイルはバイナリファイルのパーツのようになっており、これらを組み上げることで実装に動作するバイナリファイルを作ることができる。

記事本文掲載のシェルスクリプトマガジンvol.47は以下リンク先でご購入できます。